1 of 25

did:web Method

Leveraging existing trust relationships

for DIDs

Dmitri Zagidulin / @codenamedmitri

dzagidulin@gmail.com Software Engineer, Digital Bazaar / Solid Project�Co-Chair, Secure Data Storage Working Group (DIF/W3C)

2 of 25

Topics

  • What are DIDs for?
  • What’s possible, what’s easy, what’s hard
  • Where did:web fits in

2

3 of 25

About �Decentralized Identifiers�(DIDs)

4 of 25

Why do we need identifiers?

Many many reasons. Including:

Issuing Credentials of any sort.

  1. to identify the issuer (org / authority that issued credential)
  2. to identify who it was issued to

4

5 of 25

Why are identifiers hard?

  1. Governments / organizations don’t want to be responsible for them
    • a.k.a. “Why can’t we use Social Security Numbers for everything?”
  2. They often need to be globally unique
  3. Proving that you control of those identifiers�is the hardest part.
    • In person (easier) - possession of physical document, biometrics
    • Online (not so easy)

5

6 of 25

(online) Identifier Wishlist

  • Globally unique (collision resistant)
  • Portable / Reusable across use cases
  • Ability to prove control over the identifier, online
  • (Bonus) Decentralized (“bring your own Identifier”)
  • (Bonus) Resolvable (look up identifier, find out more)

6

7 of 25

Brief History of Identifiers on the Internet

Usernames�- Local to a particular domain (I’m @codenamedmitri on Twitter)�- Easy to forget�- Not portable

Emails�- Globally unique�- Slightly easier to remember�- Not portable

7

8 of 25

Brief History of Identifiers, part 2

Public Keys (e.g. PGP, used by hardcore engineers, lawyers)�- Globally unique, portable�- Impossible to remember�- Can’t revoke or change

URLs�- Globally Unique�- Almost impossible to remember�- Not portable

8

9 of 25

Proving Control of Identifiers

  • Passwords (you know a secret)
  • Magic Link (gets emailed to you)
  • Social Login (log in with Facebook)
  • Cryptographic Signatures
    • Very secure
    • Needs Key Management

9

10 of 25

Brief History of Identifiers, part 3

WebIDs and DIDs�- URLs�- Hard or impossible to remember (need apps)�- Contain proofs - can cryptographically prove control�- Secure like public keys, but:�- Allow for easier revocation / recovery

10

11 of 25

What is a Decentralized Identifier?

A new type of URL that is:

  • globally unique,
  • highly available, and
  • cryptographically verifiable.

11

12 of 25

What does a DID look like?

12

13 of 25

URNs (Uniform Resource Names, RFC 8141)

DIDs

13

14 of 25

DIDs Resolve to Documents

14

{� "@context": ["https://w3id.org/did/v0.11"],� "id": "did:v1:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD",� "authentication": [{� "type": "Ed25519SignatureAuthentication2018",� "publicKey": [{� "id": "did:v1:test:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD#authn-key-1",� "type": "Ed25519VerificationKey2018",� "controller": "did:v1:nym:DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD",� "publicKeyBase58": "DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD"� }]� }],� "service": [{� "type": "ExampleMessagingService2018",� "serviceEndpoint": ”https://example.com/services/messages”� }],� … more DID-specific information here …

}

1. Authentication

Mechanisms

3. Service Discovery

2. Public Key Material

15 of 25

We use DIDs in Verifiable Credentials

15

21

did:x:123

did:x:789

Professor

knows

Pat

Sam

name

ageOver

name

jobTitle

16 of 25

Categories of DID Methods

  1. Local/ephemeral (for example, did:key)
  2. Web-based (did:web)
  3. Distributed Hash Tables (DHTs) (IPFS, Blockstack*, etc)
  4. Distributed Ledgers (blockchains)
    1. Coin-based (public permissionless) - BTC, ETH, etc
    2. Fit-for-purpose (non-coin based, public permissioned) - Veres One, Sovrin/Indy, etc
    3. Private ledgers (Hyperledger Fabric)

16

17 of 25

DIDs - Summary

  • We need identifiers to issue credentials
  • DIDs make pretty good online identifiers
    • globally unique, portable, crypto-verifiable
  • DIDs are standardized (allow reuse / “bring your own”)
  • Work well with Verifiable Credentials

17

18 of 25

did:web

18

19 of 25

DID Challenges

  • Key Management (we’re working on it)
  • Tooling (clients for server, browsers, mobile devices)
  • Highly scalable, available architectures� a.k.a. “what’s the ops/sec throughput of your ledger?”
  • Identity proofing / Trust Anchors� a.k.a. “How do I know that did:ex:12345 belongs to the Ohio Bureau of Motor Vehicles?”

19

20 of 25

What if we could leverage existing WWW domains to serve as a storage mechanism for DID Documents?

  • Capitalize on/reuse existing trust brands. �(“Issued by FamousUniversity.edu”)
  • Most of the tooling/infrastructure familiar to devs
  • However: need to mitigate WWW drawbacks/risks.

20

21 of 25

did:web DIDs

did:web:FamousUniversity.edu

21

{� "@context": ["https://w3id.org/did/v0.11"],� "id": "did:web:FamousUniversity.edu",� "authentication": [{� "type": "Ed25519SignatureAuthentication2018",� "publicKey": [{� "id": "did:web:FamousUniversity.edu#authn-key-1",� "type": "Ed25519VerificationKey2018",� "controller": "did:web:FamousUniversity.edu",� "publicKeyBase58": "DwkYwcoyUXHNkpj3whn4DgXB4fcg9gj95vKxYN2apkZD"� }]� }],� "service": [{� "type": "ExampleMessagingService2018",� "serviceEndpoint": ”https://example.com/services/messages”� }],� … more DID-specific information here …

}

1. Authentication

Mechanisms

3. Service Discovery

2. Public Key Material

22 of 25

Linking a DID Document to a domain

  • Upload it to did:web:w3c-ccg.github.io/.well-known/did.json
  • Use the TXT field in DNS record RFC/draft-mayrhofer-did-dns
  • And also (to be explored): Link via existing TLS certificates (via key material or metadata field)

22

23 of 25

did:web Benefits

  • Re-use 30+ years of Web infrastructure and knowledge
  • Brands can leverage existing high-trust domains
  • Simple to deploy pilots/proofs-of-concept using this
  • Bridge technology to Distributed Ledger methods

23

24 of 25

did:web Challenges

  • How to prevent tampering of DID Document contents by host?
    • A: Use Hashlinks (this also gets you multi-URL redundancy)
  • What about Certificate Authority spoofs?
    • A: Over-hyped, solved by Certificate Transparency tech
  • If Hashlinks, what about key rotation / change history?
    • A: This is a challenge / work-in-progress. Need KeyBase-like cryptographic history chains (see KERI and similar work).
  • What happens if the domain (or organization) changes hands?
    • A: Tough problem (but not specific to did:web). Credible Web CG is working on it

24

25 of 25