Intro to DID Auth

From IIW
Jump to: navigation, search

DID Auth Scope, Formats, and Protocols

Tuesday 4F

Convener: Marcus Sabadello

Notes-taker(s): Karan Verma

Tags for the session - technology discussed/ideas considered: DID Auth, OpenID, OAuth

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps

- DID Auth - what it is

  • Definition:
    • A ceremony protocol where an identity owner proves to a relying party that they control a DID
    • Are the subject of a DID document.
    • Example cases:
      • Login to a website, apps, services
  • There is a challenge and response b/w identity owner & Relying Party
  • Change in terminology Moving from Identity Provider -> Identity Owner

- DID Document

  • JSON-LD based format
  • Proof not only by digital signature but also biometrics (BOPS protocol)
  • Three relevant blocks
    • Authentication
    • Public Key
    • Service
  • Question: Is there a list of authentication methods?

- DID Auth: Flows

  • Mutually authenticated channels
  • Signed HTTP requests
  • Signed emails
  • Login to website
  • Login to mobile app

What people call DID Auth?

  • Client calling a traditional rest API
    • Sign the HTTP signatures
    • did:sov:….
    • Resolver <-> DID Poc
  • Person sending email with SMTP signature
    • did:sov:…
    • Resolve, DID Auth
    • Per message basis
    • One service connecting to the other service
    • Instead of signing the payload or the http service you have mutual authentication
      • Use the TLS handshake to authenticate
      • Each will have a DID and they invoke a resolvers
      • Comment: this is better to avoid denial of service attacks
      • Comment: DID auth = proving control of the DID document. In the above cases there needs to be a priori agreement.
    • Not all chains are created equal, sovrin chain will sign the DID document to establish trust, other chains may act differently. For sovrin there are additional state proofs.
      • Resolver should give you enough information that can help you validate that the DID document is authentic.
      • Comment: people will end up doing is using a system and trust it without using state proofs.
  • Universal Resolvers:
  • Proving DID auth when we don’t rotate public key Vs when there is key rotation
    • Needs state information
    • Comment: that is in the ledger

- Using DID to login into a website(everyday tasks)

  • Credential handler API
  • The website needs to know your DID
    • Typing your DID in the website
    • Javascript API for the browser
    • QR codes
  • Websites looks up the DID document using a resolver
    • Website sends a challenge
    • Agent Hub DID Auth asks to solve a challenge
    • User proves that “I am me”
      • Comment: The login button can ask more than just you “I am me” but also attributes/credentials about you.
      • Examples: Age, Driving License
    • What happens if the server is offline?
      • Answer: caching
    • Oauth and OpendID connect is applicable to DID workflow.
  • Challenge can be delivered as
    • QR code
    • Javascript code
  • Standardize: messages, protocol
  • There are flows that overlap with Oauth and OpenID connect

Look at draft at