Intro to DID Auth
From IIW
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