Intro to DID Auth

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
• DID-TLS
  • 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: uniresolver.io
• 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 weboftrust.info