Decentralized Identifier WG

TPAC Sessions

Day 1: September 23, 2024

Chairs: Gabe Cohen, Will Abramson, Dan Burnett

Location: Hilton Anaheim, 4th Floor, Capistrano

1

Welcome!

• Logistics
• IRC and Scribes
• W3C WG IPR Policy
• Introductions & Dinner
• Agenda

2

Logistics

• Location: Hilton Anaheim, 777 W. Convention Way, Anaheim, California, 92802, USA
• Meeting room: 4th Floor (Concourse level), Capistrano room
• WiFi: SSID is “W3C-TPAC2024”, password is “anaheim24”, IRC: #did
• Online joining instructions (member confidential): https://www.w3.org/events/meetings/29989aad-dcba-4bef-9167-76cbc6fc4d3d/
• Restrooms: Out the room doors, head right and go back towards the elevators and escalator
• Meeting time: 9 am - 6 pm, Sep. 23-24
• Breaks: 10:30-11 am; 12:30-1:30 pm (Day 1)/1-2 pm (Day 2); 4-4:30 pm
• TPAC Agenda: https://www.w3.org/2024/09/TPAC/#schedule
• DID WG Agenda: Day 1, Day 2
• These (live) slides: https://tinyurl.com/didwg-tpac2024-slides (Google Slides)
• Dinner Details: See the “Dinner Tonight” slide

3

IRC and Scribes

• Meeting discussions will be documented
• Text Chat: http://irc.w3.org/?channels=did
• IRC://irc.w3.org:6665/#did
• Joining instructions
• https://www.w3.org/events/meetings/29989aad-dcba-4bef-9167-76cbc6fc4d3d/ (member confidential)

4

W3C WG IPR Policy

• This group abides by the W3C patent policy�https://www.w3.org/policies/patent-policy/20200915/
• Only people and companies listed at https://www.w3.org/groups/wg/did/participants/ are allowed to make substantive contributions to the specs
• Code of Conduct https://www.w3.org/policies/code-of-conduct/

5

Introductions & Dinner

• Introductions

​

• Expected count for dinner:
• Dinner proposals:
• Currently have a booking for 14 @Savor Stone Hearth Pizza and Wine at 6.30pm (6 minute walk) thanks to Erica. Will need to at least update numbers for this.
• If there is strong preference for somewhere else we can look into that. Options on the next slide

​

6

Suggested dinner options

Savor Stone Hearth Pizza and Wine (upscale pizza) - $$ - 6 min walk https://www.savorpizzaandwine.com/ �Currently: Reservation for 14

Tangerine Room - $$ - 15 min walk https://www.tangerineroom.com/

Craft by Smoke and Fire - $$ - 12 min drive https://www.craftbysmokeandfire.com/menu

Haven Craft Kitchen and Bar - $$ - 15 min drive https://www.havencraftkitchen.com/our-menu#menu=dinner-ordering

​

​

Solita Tacos & Margaritas - $$ - 9 min drive https://solitatacos.com/menus/

O Sea (seafood) - $$ - 12 min drive https://www.eatosea.com/menus/#dinner

The Peel - $$ - 9 min drive https://www.peelcraftbar.com/

Byblos Cafe (Mediterranean) - $$ - 14 min drive https://www.byblos.cafe/#menu-section

7

And still more here: https://docs.google.com/document/d/1zGseZW0sDL50-Fq45PVN2zY5EK8XxbLrvf88MOnLUJo/edit

Potential topics for the “Open Topics” sessions

• Minimum criteria for DID Method standardization at W3C? (Manu)
• Meaningful & effective decentralization (Gabe)
• Future proofing to support MPC based multisig, in particular FROST. (ChristopherA)
• Controller property (Joe)

8

Agenda: Day 1

9

State of the Industry (30 min) — Manu, Gabe

10

Overview

• Decentralized Identifiers are in production!
• The following slides summarize:
• How some of these projects are using DIDs,
• The number of people using DIDs today,
• The potential number of people using DIDs for each project.
• We will cover some upcoming events and challenges at the end

11

Bluesky

Details

• did:plc - Placeholder DID Method
• DID PLC is a self-authenticating DID which is strongly-consistent, recoverable, and allows for key rotation.
• Supports a permanent, publicly accessible history.
• Meant to be temporary until a better DID Method comes along. Run out of a centralized registry.

Today: Over 10,062,511 DIDs on Bluesky

Potential: Could grow to hundreds of millions to billions

12

TruAge

Details:

• did:key - Ephemeral key-based DID Method
• A simple, non-registry based DID Method based on expanding a cryptographic public key into a DID Document.
• Used to identify issuers and holders in the ecosystem.
• Convenience store sector expanding usage of Verifiable Credentials (and DIDs) beyond age verification - coupons, loyalty, payments, digital receipts (potential to use did:web here)

Today: Several hundred thousand in TruAge

Potential: 200M+ in US at scale, with 52 million age checks per day

13

California Department of Motor Vehicles

Details

• did:jwk and did:web
• Used to identify CA DMV issuer and holder devices in Verifiable Credentials

Today: 600K with ~1.2K added per day

Potential: 27-34 million people in California with IDs through the State

​

14

US Department of Homeland Security (USCIS)

​

Details

• did:web* - did:web with did:tdw-like enhancements (e.g., DNSSEC)
• Used to identify DHS issuers

Today: Readying for deployment

Potential: 43 million permanent residents and naturalized citizens

​

15

Switchchord

Details:

• did:web
• Used to model legal relationships between music publishers and songwriters and route data about new music into existing catalog management systems.

Today: one music publisher with 10 songwriters; one publishing administrator that represents ~8,000 songwriters (current pilot is limited to 100); and ~100 independent songwriters.

Potential: 10M+ creator economy musicians, plus thousands of record labels and music publishers.

16

European Blockchain Services Infrastructure (EBSI)

Details:

• did:key extension (canonicalized JWK value)
• A W3C-compliant, privacy-preserving and GDPR-compliant did:key method.
• did:ebsi for Legal Entities; uses a permissioned blockchain network across Europe

Today: ???

Potential: 449 million+ people

17

Bhutan National Digital Identity (NDI)

Details:

• Launched in 2023 to create a national digital trust ecosystem in Bhutan
• Facilitates p2p interactions between individuals, governments, and organizations, accelerating digital adoption and access to financial and other services.¹
• Uses did:sov, using the Indicio Network and Hyperledger Indy blockchain.

Today: ???

Potential: 790,000+ people

18

1. https://trustoverip.org/wp-content/uploads/Case-Study-Bhutan-NDI-National-Digital-Identity-ToIP-Digital-Trust-Ecosystems-V1.0-2024-05-21.ext_.pdf

Velocity Network

Details:

• Focused on career records, and the Internet of Careers®
• did:velocity for credentials, uses the Velocity Distributed Ledger
• did:ion for organizations and individuals, a L2 that uses Bitcoin

Today: 70+ companies.¹ 1M+ credentials issued in 185 countries.²

Potential: Millions of workers, worldwide.

19

1. https://www.velocitynetwork.foundation/foundation#!general
2. https://www.velocitynetwork.foundation/velocitys-2023-recap-the-internet-of-careers-is-live

TBD

Details:

• TBD is a business unit within Block (formerly Square)
• Focused on KYC, KYB, and providing identity for regulated financial use cases.
• Uses did:dht, did:web, and did:jwk.

Today: DIDs created in the 3M+ range (mostly did:dht).

Potential: Millions of individuals and businesses using Square, Cash App, Afterpay and other Block products worldwide.

20

…. and more…

Privado iD: An EVM-based set of tools for developers to use W3C VCs and DIDs for use cases like age verification, national ID, content authenticity, and more. Uses did:polygonid.

Dock: Customer onboarding acceleration with reusable ID. Uses a proprietary blockchain for did:dock (now merged with Cheqd).

Cheqd: Payment and trust infrastructure for credentials (now merged with Dock). Uses did:cheqd, a Cosmos-blockchain based DID method.

Walt.id: Digital identity and wallet infrastructure used by 10k+ developers and organizations. Supports did:key, did:jwk, did:web, did:cheqd.

21

…. many more!

Microsoft Entra: Supports did:web as part of the Entra Verified ID suite.

Trinsic: An identity acceptance network. Supports 16,000+ document types in 220+ countries. 20+ reusable ID schemes. 60M+ pre-verified users. Uses did:key.

IOTA Identity Framework: Uses the did:iota method to facilitate a general purpose identity network for people, organizations, things, and objects.

GLIEF: Verifiable Legal Entity Identifiers powered by did:webs. GLIEF has issued over 2.7M legal entity identifiers as of September 2024.

… and still many more!

​

​

​

22

Challenges

• No standardized DID Methods (and governments need them)
• Pushback on DIDs by some in the European Union?
• did:web is lacking desired features for large organizations
• Even did:plc creators want something better
• People still want a standardized "decentralized" DID Method
• Will a DID Methods Charter get approval at W3C?

​

23

A brief history of DIDs (30 min) — Drummond

24

PART ONE: Early History

25

(The following slides are from the first meeting of the W3C DID Working Group on Sept. 16, 2019)

Timeline

26

2015

2016

2017

2018

2019

Where did the term “DID” come from?

27

28

29

Why did the U.S. Department of Homeland Security fund development of the DID spec?

30

Four reasons:

1. A permanent (persistent) identifier

It never needs to change

• A resolvable identifier

You can look it up to discover metadata

• A cryptographically-verifiable identifier

You can prove control using cryptography

• A decentralized identifier

No centralized registration authority is required

31

URNs (Uniform Resource Names, RFC 8141)

DIDs

32

How widely are DIDs in use today?

33

Some statistics

• There are currently 32 DID methods registered in the informal W3C Credentials Community Group DID Method Registry
• https://w3c-ccg.github.io/did-method-registry/
• Three for Bitcoin
• Six for Ethereum
• The Sovrin Foundation currently has 71 stewards around the world hosting a public permissioned distributed ledger for DIDs
• The Canadian provinces of British Columbia and Ontario have issued over 1.4 million verifiable business license credentials based on DIDs

34

For a full history, see:

35

https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/�did-primer-extended.md

PART TWO: A Quick Update

36

(The following slides are from an Evernym webinar given a few weeks after the W3C vote on DID 1.0)

37

38

39

40

41

42

43

44

Morning break (10:30)

45

DID Method Standardization (30 min) — Kim

46

Agenda

1. Introduction and Welcome
2. Context & Status
3. About the DIF DID Method Working Group
4. Participation & Logistics
5. Expected Outcomes
6. Discussion

Context & Status

​

• Released DID Method Standardization Letter of Intent
• https://identity.foundation/publications/LOI-DIDMethodStandardization.pdf
• >100 signatories registered interest
• Identified 3 Work Streams
• DIF Working Group: Kick-off meeting last week
• W3C Working Group: Presenting at TPAC
• Broader Community Engagement: did-method-standardization
• Clarified Mission & Goals​: https://github.com/did-method-standardization/organization/blob/main/mission_goals.md

​

DID Method Working Group Overview

Purpose

Accelerate standardization of DID methods, collaboratively with key organizations

Key Activities

1. Identify methods across three categories

3. Develop techniques to support broader standardization efforts

4. Contribute to relevant standards bodies

DID Method Categories

• Web-based

• Ephemeral

• Decentralized methods

Working Group Goals

Select Initial Methods

Choose and advance standards for key DID methods across the 3 categories.

Develop Scalable Approaches

Create frameworks for independent, scalable DID method standardization, based on DID Traits, Rubric

Standardize & Advance to Maturity

Progress DID method standards through appropriate Standards Development Organizations.

Working Group Efforts, Detailed

Mature Specifications

Working group-approved specifications for initial DID methods.

SDO Collaboration

Establish new W3C DID Methods Working Group for broader standardization, and TBD other organizations

Test Suites

Create comprehensive test suites and conformance criteria for DID methods.

DID Method Standardization Empowerment

Enable broader standardization efforts across any organization

Ecosystem Growth

Enable increased adoption of DIDs across various sectors and use cases.

Expected Outcomes

Participation & Logistics

Participation Requirements

1

Membership

Member of one of the following organizations

• DIF

• ToIP

• W3C CCG or DID WG

• IOTA

2

Sign Feedback Agreement

Sign the Working Group Feedback Agreement to participate

3

Code of Conduct

Adhere to DIF Code of Conduct for respectful and productive collaboration.

DIF Working Group Processes

1

Transparent Development, W3C License

GitHub for open collaboration and version control of specifications. Github and slack or mailing list enables asynchronous progress towards goals. DIF uses W3C license for specifications.

2

Regular Meetings

Regular meetings to push forward steady progress, especially if agreement can’t be reached asynchronously.

3

Consensus Decision Making

Use consensus-based approach for key decisions and direction. Specifications move through WG Draft to WG Approved to final approval

Next Steps

DIF SC Approval

Expected by 2nd week of October.

Select Co-Chairs

Let us know if you're interested.

​

Chair: Markus Sabadello

Interim Chairs: Kim. Gabe

​

Find recurring time

We need to select a recurring meeting time.

Select comm channel

For coordination, notification, and discussions outside of Github when needed.

Slack, mailing list, or both

https://us02web.zoom.us/survey/t6YV3IibGYy6QjL1D1qC-k3SmCuCFPmG6vgE6qPbXtZQW83rE3I.a8IWvg7FxBSujcNl/view?id=pbPJdu_oRJm1BnuRj5q_Dw#/sharePreview

Poll:

Thank you & Discussion

Open floor for questions and comments

Self-describing DID Methods (15 min) — Kevin Dean

58

The Problem

• DID method names are not guaranteed to be unique
• Generated autonomously by the authors of their respective specifications.
• May be mitigated by registering the method in DID Extensions (optional).
• Lack of version control
• Vulnerability may require scrapping the DID method altogether.
• No way to advertise a correlation between the previous DID method and the replacement DID method.
• May be mitigated by including a version number in the method-specific identifier (not standardized).

Requirements

• Collision
• DID method names SHALL be generated in such a way that there is a negligible risk of collision.
• Security
• DID method names SHOULD be generated in such a way that they can be verified against some external, related content.
• Version Control
• DID methods SHOULD advertise compatible DID methods that are usable without modification in processes involving the original DID method.
• DID methods SHOULD advertise a replacement DID method that is an upgrade to the original DID method, not guaranteed to be usable without modification in processes involving the original DID method.

Semantic Versioning

• Versioning SHOULD align with the MAJOR.MINOR.PATCH concepts behind Semantic Versioning 2.0.0, namely that:
• incrementing the MAJOR version denotes incompatible API changes;
• incrementing the MINOR version denotes functionality added in a backward-compatible manner; and
• incrementing the PATCH version denotes bug fixes made in a backward-compatible manner.

Semantic Versioning

• A MAJOR.0.0 version SHALL advertise all its MAJOR.MINOR.0 (MINOR ≠ 0) versions as usable without modification.
• A MAJOR.MINOR.0 version (MINOR ≠ 0) SHALL advertise the next MAJOR.MINOR’.0 (MINOR’ = MINOR + 1) version as usable without modification.
• A MAJOR.MINOR.0 version SHALL advertise all its MAJOR.MINOR.PATCH (PATCH ≠ 0) versions as usable without modification.
• A MAJOR.MINOR.PATCH version (PATCH ≠ 0) SHALL advertise the next MAJOR.MINOR.PATCH’ (PATCH’ = PATCH + 1) version as usable without modification.
• All MAJOR.MINOR.PATCH versions SHALL advertise the next MAJOR’.0.0 (MAJOR’ = MAJOR + 1) version as an upgrade, not guaranteed to be usable without modification.
• Any MAJOR.MINOR.PATCH MAY advertise any later MAJOR.MINOR’.PATCH’ (MINOR’ = MINOR and PATCH’ > PATCH or MINOR’ > MINOR) version as usable without modification.

Semantic Versioning

63

Method Name Generation

• Names SHALL be set by some well-defined randomization algorithm (COLLISION). Some options are:
• random fixed-length string generation using a cryptographically secure pseudorandom number generator;
• UUID generation per RFC 9562 (version 7 recommended), minus hyphens; and
• the hash of some document accessible to users of the DID method.
• The last option could be implemented as the hash of the DID method specification (SECURITY).
• For the sake of this discussion, that option will be assumed.
• For future-proofing, the hash SHALL be represented using multihash, encoded in lowercase Base36 to minimize the method name length.

Version Advertisement

• There SHALL be a way to query a DID method, in a way that is accessible to all parties authorized to use the DID method, either in DID generation or in DID verification, for new versions of itself.
• If there are restrictions around the use of a DID (e.g., access to the DID method’s verifiable data registry requires presentation of some authorization token), those same restrictions MAY apply to querying the DID method.
• Three options for the DID method to provide this data are:
• within the DID document data (assuming it is updatable);
• within the DID document metadata (assuming it is updatable); or
• via a service associated with the DID.
• The mutable nature of the version data better aligns with the concept of a service.
• The "Version” (proposed) service type can be included in every DID document for the method, allowing the query to take place using any DID for the DID method.

Implementation

• Because the method name is the hash of the method specification, it’s not possible to include the method name in the specification itself.
• Instead, the specification SHALL include the following statement:
• The method name for this specification is the <hash algorithm name> hash of this document, represented using multihash, encoded in lowercase Base36.
• For the DID representing the DID method to be known, the specification MAY include the following statement:
• The DID representing the DID method for this specification is did:method-name:<method-specific-id>.
• Depending on the algorithm for generating the method-specific ID, it may not be possible to know it at the time that the specification is finalized, so it may instead be shared through some out-of-band mechanism.

Standardization

• The preferred option is to update the DID standard to support self-describing DID methods.
• Class 4 change, hence out of scope of the current charter.
• The alternative is to register a new DID method (e.g., “x”), to support self-describing DID methods as sub-methods. This would include registration of the additional attributes and the "Version” service type.

Example

• Bitcoin-based DID method:
• The method name for this specification is the SHA-256 hash of this document, represented using multihash, encoded in lowercase Base36.
• The DID representing the DID method for this specification is did:method-name:bc1qsvqcrsqhzmsfrn45jlsctsfmjw7yeq38dvn9v2.
• Once finalized, the hash is calculated and the final DID for the method is determined to be did:mugx0x8lmmlu9m5ysvjrq222spgz8aovnrgbco63zzuutdztwbsu:bc1qsvqcrsqhzmsfrn45jlsctsfmjw7yeq38dvn9v2.
• Method name and DID are published to the (private or public) community, with DID document including a “Version” service endpoint.

Scenarios

• See document for details.
• DID Method Development
• Patch Version
• DID Creation
• Minor Version
• Minor Version Presentation
• Major Version
• Major Version Presentation

Questions?

Kevin Dean�kevin@legreq.com

​

https://github.com/LegReq/Self-Describing_DID_Methods

70

DID DHT (15 min) — Gabe

71

DID Methods Comparison

​

did:jwk

(+) Self-resolving key that always has the latest state

(-) No updates

(-) No way to signal compromise

did:web

(+) Domain based method

(+) Supports updates

(-) Relies on TLS certs

(-) Relies on DNS / domain registrars

(-) No historical state resolution

did:ion

(+) Supports any DLT and Content-Addressable Storage

(+) Permissionless + full featured (update, recovery, deactivation)

(-) Complex architecture

(-) Uncertain if you have the latest state / pinning risk

72

Why move away from ION?

Usability issues & technical complexity

Can we do better?

73

Enter did:dht

A new free, fast, efficient, massively decentralized DID method

74

What’s a DHT?

75

BitTorrent

76

BitTorrent in Numbers

18

Years of activity

15M+

Active nodes

1000s

Organizations using it!

77

What’s DID DHT?

• Built on BitTorrent’s DHT
• Supports most necessary features of a DID
• Built in anti-spam measures
• Optional discovery mechanism via Bitcoin (ideas for more!)
• Potential for interop with widely supported did:key and did:jwk methods; upgrades existing methods
• Bonus: friendly name indexing!

78

What’s DID DHT? (contd.)

• Ed25519 key required
• 1000 byte maximum payload size
• Defined a mapping of DIDs to DNS resource records
• Moving to CBOR as a more efficient format
• Running a free public Gateway today (over 3M+ registered!)
• Client impls available in Kotlin, Go, JS/TS, Dart, Swift, Rust

79

Where We’re At

80

Q4 2023

Beyond

​

• Production ready open-source serve
• Default DID method for TBD
• Socialize and improve spec, server code

Q1-3 2024

• Client implementations in Kotlin, Typescript, Go
• Server implementation in Go, running on TBD infrastructure
• Used across TBD products and partner hackathons (like the Africa Bitcoin Conference)

• Standardization in ???
• CBOR instead of DNS
• Universal resolver plugin
• Gossip support (?)
• Disclosable DID Documents (?)

​

One More Thing…

The DID method to end all DID methods?

81

BTCR lessons learned and improvements (15 min) — Joe Andrieu

82

BTCR Lessons Learned and Improvements

TPAC 2024

Agenda

• Motivations
• Pain Points
• Solutions
• Next Steps

Motivations

• Fix BTCR
• Retain censorship-resistant features of BTC
• Enable more flexible use cases
• Iterate from best practices
• Lessons learned from did:eth, did:ion, did:btc, did:sol
• Enable better cryptographic and privacy guarantees

85

Pain Points

1. Offline Creation
2. Aggregation
3. Late publishing
4. Privacy
5. Resilience
6. Resolution Scope
7. Update Delegation & Attenuation

​

Solutions

1. Beacons
1. Service endpoints for discovering update announcements
2. How controllers announce DID document updates
3. How resolvers discover DID document updates
2. zCaps
• Data integrity secured JSON-LD using JSON Patch
• How we authorize updates
• How we invoke updates
3. Guaranteed Invariant Provenance
• Strict ordering and complete coverage of all update signals,
1. independent of when resolution occurs.
• How we ensure legitimacy of DID document state
4. Sidecar
• Independent, privacy delivery of update payloads, secured by cryptographic commitment
• How we enable non-public DID documents and updates

Beacons

• Beacons announce updates in BTC spends
• Service Endpoint to watch for updates
• Signals & Updates signed by controller
• Evolving tapestry of legitimate authorities
• Pain Points Addressed
• Aggregation
• Late publishing
• Resolution Scope
• Offline creation

{

"id": "#smt_aggregated",

"type": "MerkleAggregator",

"serviceEndpoint": "bitcoin:tb1pfdnyc8vxeca2zpsg365sn308dmrpka4e0n9c5axmp2nptdf7j6ts7eqhr8"

}

​

​

Beacon Signal: TxOut of format [OP_RETURN, <32 bytes>]

zCaps

1. DID updates are zCap invocation of a JSON patch to DID document
2. JSON patch supports arbitrary mutations to JSON
3. “Root authority” is the initiating DID
4. Root capability deterministically generated from did:btc1 identifier
5. Authorization tied to previous DID document verification methods and relationships
6. Pain Points Addressed
1. Update delegation and attenuation

Root capability for did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a

​

{

"@context": "https://w3id.org/zcap/v1",

"id": "urn:zcap:root:did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a",

"controller": "did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a",

"invocationTarget": "did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a"

}

​

Guaranteed Invariant Provenance

• Resolvers
• Walk the btc chain
• Process all timely signals
• Any inconsistency = Invalid DID
• All updates signed by controller
• Updates version DID document
• Updates to same version must be equivalent
• Pain Points Addressed
• Late publishing
• Resilience
• n:n signature authority for every update
• All signals must resolve

did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a

v1

v2

v3

v4

=?

Initial DID document

u1

u2

u3

u2

Beacon signals

Sidecar

resolve(did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a, resolutionOptions)

1. Updates provided out of band to resolver by DID controller
2. Resolvers check updates match those announced by beacons
1. How can the DID resolver support sidecar data inputs?
3. Pain Points Addressed
• Offline creation
• Privacy

U1

U1

U1

U1

v1

U1

u1

+

Sidecar Data

Next Steps

• Conversations at TPAC
• Suggestions for DID Core and DID Resolution
• Version
• Sidecar in resolution
• Questions
• zCaps use, especially signing
• Issues & Iterations at BTC1 repo

Come talk to us about it during TPAC

• Joe Andrieu <joe@legreq.com>
• Will Abramson <will@legreq.com>
• Kevin Dean <kevin@legreq.com>
• Jennie Meier <jennie@contract.design>
• Dan Pape <dpape@contract.design>

​

Spec: https://github.com/dcdpr/did-btc1

Thanks

Special thanks to Ryan Grant and Digital Contract Design for continuing to support this work.

ZCap Invocation to update did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a

​

{'@context': [... ],

'patch': [

{'op': 'add',

'path': '/service/4',

'value': {

'id': '#linked-domain',

'type': 'LinkedDomains',

'serviceEndpoint': 'https://contact-me.com'

}}

],

'proof': {...}

}

ZCap Invocation to update did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a

​

{'@context': [... ],

'patch': [... ],

'proof': {

'type': 'DataIntegrityProof',

'cryptosuite': 'secp-schnorr-2024',

'verificationMethod':'did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a#initialKey',

'invocationTarget':'did:btc1:k1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a',

'capability': 'urn:zcap:root:did%3Abtc1%3Ak1t5rm7vud58tyspensq9weyxc49cyxyvyh72w0n5hc7g5t859aq7sz45d5a',

'capabilityAction': 'Write',

'proofPurpose': 'capabilityInvocation',

'proofValue':'...'

}

}

Lunch (12.30)

97

Work Item Inventory (15 min) — Chairs

98

Charter Deliverables and Status

​

• Our Charter includes:
• DID Specification Registries, including transitioning it from a WG Note to a W3C Registry.
• DID Method Rubric, including transitioning it from a WG Note to a W3C Registry.
• The Plain CBOR representation.
• DID Implementation Guide v1.0.
• With Deliverables
• Decentralized Identifiers (DIDs) v1.0
• Decentralized Identifier (DID) Resolution and DID URL Dereferencing v1.0
• And…
• The Working Group may also publish new Working Group Notes
• But Don’t Forget About…
• Test suites!

99

W3C Technical Report Process

• Working Draft (WD) - does not imply consensus
• Candidate Recommendation (CR)
• Entry - to publish as CR, the document is expected to be feature complete, have had wide review, and must specify the implementation requirements needed to exit
• Exit - to exit CR (and move to PR), the document must satisfy the stated implementation requirements; it must also not have made any substantive change not warned about upon entry
• Proposed Recommendation (PR)
• Basically a one-month sanity check during which the AC is encouraged to have any final review and discussion, but if anything major happens it’s a fail (requiring a move back to CR or earlier)
• Recommendation - Done
• But errata are possible

100

Timing of our primary spec

​

April 2026 (REC)

​

Jan 2026 (PR)

Nov 2025

(CR2)

Aug 2025

(CR1) .

Sept 2024

(FPWD)

https://www.w3.org/policies/process/20231103/

​

Jan 2025

(Feature freeze)

Goals for this meeting

• DID Resolution
• Identify and prioritize rocks
• Other Normative Deliverables
• A solid timeline for CR
• Non-normative deliverables
• A full understanding of the set of work for each

102

DID Registry Process (30 min) — Christopher Allen

103

Some History

• Tension going back to RWOT2 (2016) between:
• Need to avoid name collisions
• Risk of centralization of decentralization
• W3C DID 1.0 Consensus
• First come, first serve; minimal requirements
• Delegated to to W3C CCG during interim

104

Current Method Registry

• Key requirement is a link to acceptable method spec
• But also review of IP and moral issue of name
• Currently 198 methods registered
• CCG has new (trained early 2024) team reviewing registrations, no backlog
• There are a number of problematic entries with no approved process to fix
• Contact no longer available
• Ownership change
• Some method specs no longer available
• Version change
• Desire to expire

105

DID WG 1.1

• We agreed to split out the current DID method registry from other DID extensions.
• Our charter requires we “Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.”
• As a WG, we can also now do official W3C registries.
• We don’t have consensus on processes to resolve current method registration difficulties
• There also is some desire to:
• Have the list be shorter
• Be able to differentiate registered methods

106

One proposal

• We continue to have the CCG volunteers maintain the base “method registry”,
• Primary goal to avoid name collisions
• Continue with minimal spec requirements.
• Have some simple policies to address current problems
• These will be considered “provisional” for period (1-½ years?)
• A new PR each period can renew “provisional” for another period, otherwise removed.
• That the DID 1.1 WG maintain additional lists, possibly including:
• Some proof of implementation in code and any deployment status
• Conformance to the DID Resolution test suite
• Supports some minimal web-based API
• These additional lists are not W3C registries, more like Notes, and are not required to “be” a DID.

107

DID Methods (30 min)

108

109

110

DID Extensions (30 min)

111

112

DID Rubric (30 min) — Joe Andrieu

113

Rubric for Decentralization of DID Methods

JOE ANDRIEU

DID WG FACE TO FACE TPAC 2024

JOE@LEGREQ.COM

Agenda

• Why a rubric
• Our approach
• Work to Date
• Lessons Learned
• Next Steps

​

Why a rubric

• Defining “decentralized” intractable
• How decentralized MUST a method be?
• And yet… there are commonalities
• A Rubric offers a way forward
• Method of evaluation (from education)
• Multi-dimensional
• Tailored to specific goals

What is a rubric?

• A set of criteria
• specific questions
• specific possible responses
• explanation of how what each response means
• Can be consistently applied
• by different evaluators
• on different students/projects/products

Our approach

• Initially limited to “decentralization”
• Capture the motivations of DID community
• Not exhaustive
• pick what matters
• NOT an authority for evaluations
• Make it easy for others to evaluate & compare

Work prior to WG

• Several IIW sessions
• Google docs set of questions
• Included in DID WG charter
• RWOT9 Paper (started in Sept)
• Six co-authors

Joe Andrieu joe@legreq.com , Shannon Appelcline shannona@skotos.net, Amy Guy amy@rhiaro.co.uk, Joachim Lohkamp joachim@jolocom.com, Drummond Reed drummond.reed@evernym.com, Markus Sabadello markus@danubetech.com, Oliver Terbu oliver.terbu@consensys.net, and Kai Wagner kai@jolocom.com

Lessons Learned - Subjectivity

• Beauty is in the eye of the Evaluator
• Know your use cases
• Pick the most relevant criteria to you
• Record
• Evaluator, Date, Use Cases
• Document your reasoning for each response

Lessons Learned – Categories Matter

• Governance
• Rulemaking, Operations, Enforcement
• More than Governance
• Alternatives
• Adoption

Lessons Learned – Architecture

• Many criteria need to be applied across different architectural layers
• The layers vary
• Consolidating by layer GREATLY simplified the reports

Lessons Learned – Examples

• Examples are vital
• Can’t include everyone
• Proposed constraints
• ONLY 3 examples for each criteria
• Examples should highlight differences
• Need help from Method implementers

Lessons Since Publishing

• n x n + 1 Learning Curve
• Must know DID Method, the use case, AND the Rubric.
• March 2022 Evaluations
• did:web, did:ion, did:v1
• https://didevaluations.com
• HTML is bulky

The Initial Goal: A Litmus Test

• A DID Method is “decentralized” if…

​

• Anyone can verify proofs created by any DID Controller without reliance on a central authority.

Next Steps

• Break into .json files
• Define as W3C Registry
• Needs formal rules
• Needs formal approval from WG
• Think about namespace
• Align / Integrate with DID Traits work

​

DID Traits, Feature Sets (30 min) — Dmitri

127

What are DID traits?

"LEGOs for DID method authors" (Design patterns of DID method construction)

Part of rubrics (technical affordances)

Example traits:

• Immutable vs mutable
• Support for service endpoints
• Support for alsoKnownAs
• Self-certifying identifiers
• Key rotation event logs / history
• Pre-rotation
• DID relative URLs

128

• Revocable / deletable
• Is the DID method signed?

did:key traits

Deterministic

Immutable

Offline capable

No support for: service endpoints, alsoKnownAs, history. more than one key

129

did:web traits

Mutable, revocable, deletable�Support for many key types, multiple keys

No key rotation history

Not self certifying�

• Supports alsoKnownAs
• Supports controller property
• Service endpoints,

130

did:tdw traits

• Mutable, revocable, deletable
• Self certifying identifier
• Key rotation history log
• Pre-rotation
• /whois
• Supports alsoKnownAs
• Supports controller property

131

did:dht traits

• Mutable, revocable, deletable
• Updates through non-rotatable identity key pair
• Multiple keys, multiple key types
• Supports alsoKnownAs
• Supports controller property
• Supports service endpoints

​

132

See also

https://identity.foundation/did-traits/

133

Afternoon break (16.00)

134

Controller Documents (60 min)

135

What is a "Controller Document"?

• A generalized type of DID Document that allows for ANY URL to be used in the document.
• The "class" that DID Documents inherit from.
• Current plan is to make the DID Core specification depend on the Controller Document specification.

136

… the plan is on track, more-or-less, with some weirdness

• VCWG is responsible for the Controller Document (due to Process issues, we weren't chartered at the time)
• Controller Document exists mainly because a few people didn't want to normatively reference DID Core or Data Integrity
• We were supposed to directly copy text from DID Core, but have ended up modifying it slightly

137

What's in the Controller Document today?

• Same properties as in DID Core: id, controller, alsoKnownAs, verification relationships and methods
• New-ish stuff:
• Normative JsonWebKey and Multikey definitions
• Multibase definition and base-encoding/decoding
• Algorithms for fetching keys and base-encoding/decoding
• JSON-LD Contexts that don't depend on DIDs

138

What is the timeline?

• Need to respond to TAG and PING review comments
• Pretty much ready for 1st Candidate Recommendation
• Expect 1st Candidate Recommendation in Nov-Dec 2024

139

Discussion

• service isn't in controller document, should it be?
• service isn't in VCDM, should it be (in v2.1 or v3.0)?
• Do we want to request transfer of Controller Document to this group?
• Are there any concerns about the current path?

140

What's Interoperability? How can we test/demonstrate it? (30 min) — Dmitri

141

What is interoperability?

• What's in a DID?
• 1) bag of keys
• 2) bag of service endpoints
• 3) alsoKnownAs
• 4) (possibly) controller hierarchy

​

• Interop within a DID method vs interop between DID methods

142

who is concerned with interop?

What is a DID used for?

1. Signing stuff (authn, VCs, etc)
2. Encryption/decryption
3. Routing
4. Aliases (alsoKnownAs)

​

143

Interop between DID methods

First and foremost. interop on the policy level

That is does a given system (issuer, verifier, agent) even intend to support a given DID method?

Currently, most deployed issuers, verifiers, and wallets support a small curated subset of DID methods.

Why? Affordances, tech constraints, library support, governance, policy, level of confidence

144

Interop within a DID method

• Registration testing (where applicable)
• Resolution testing

Watch for:

• Key type support
• Which service endpoints are allowed
• Are custom properties allowed?
• Infrastructure complexity (authentication, gas fees, etc)

145

Practical Interop Concerns

For a given DID method, how many registrar and resolver libraries in various languages?

For signing (e.g. VC issuance), do issuers and verifiers support a given set of DID methods? (interop through wide usage)

Similar question for authn (RPs), encryption, routing.

DID interop basically tied to the use case.

​

​

​

146

Bonus: DID based signature validation concerns

(beyond key type support)

Which Issuer and Verifier Registries support this DID method?

​

What about historical verification? (key rotation events, observers. logs, anchoring in time)

147

Dinner Tonight: 6:45

https://www.savorpizzaandwine.com/

6 minute walk

​

MEET: 6:30 Hilton Anaheim Lobby (If you’re late, you’re on your own)

148

Decentralized Identifier WG

TPAC Sessions

Day 2: September 24, 2024

Chairs: Gabe Cohen, Will Abramson, Dan Burnett

Location: Hilton Anaheim, 4th Floor, Capistrano

149

Agenda: Day 2

150

IRC and Scribes

• Meeting discussions will be documented
• Text Chat: http://irc.w3.org/?channels=did
• IRC://irc.w3.org:6665/#did
• Joining instructions
• https://www.w3.org/events/meetings/29989aad-dcba-4bef-9167-76cbc6fc4d3d/ (member confidential)

151

Extensibility of DID Resolution and DID URL Dereferencing (30 min) — Markus

152

Resolving DIDs

did = "did:" method-name ":" method-specific-id

resolve(did, resolutionOptions) →� « didResolutionMetadata, didDocument, didDocumentMetadata »

153

Dereferencing DID URLs

did-url = did path-abempty [ "?" query ] [ "#" fragment ]

dereference(didUrl, dereferenceOptions) →� « dereferencingMetadata, contentStream, contentMetadata »

154

Examples of DID URLs

did:example:123456789abcdefghi#key-1

did:example:123?versionTime=2021-05-10T17:00:00Z

did:example:123?transformKeys=JsonWebKey

did:example:123?noCache=true

did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com#whois

did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com/whois

did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com/whois#vc1

did:tdw:Qma6mc1qZw3NqxwX6SB5GPQYzP4.example.com/governance/issuers.json

did:cheqd:mainnet:46e2af9a?resourceName=degreeLaw&resourceType=JSONSchema

did:example:123?service=DecentralizedWebNode&queries=W3sgTUV

155

Where is

it specified?

156

DID URL Dereferencer Functionality

Method-independent functionality

Method-dependent functionality

Where is it specified?

Where is it specified?

?service=

DID Core and DID Resolution

?hl=

DID Core and DID Resolution

?versionTime=

DID Core and DID Resolution and DID Method Spec(s)

?resourceName=

DID Resolution Extension and DID Method Spec(s)

?oobi=

DID Method Spec(s)

/whois

DID Method Spec(s)

?noCache=

DID Resolution

/governance/issuers.json

DID Method Spec(s)

?transformKeys=

DID Resolution Extension

Application Functionality

Where is it specified?

?queries=

Application Spec

DID Resolution Open Discussion (30 min)

157

158

Morning break (10.30)

159

DID Resolution Issue & PR Processing (Markus, 120 min)

160

161

Lunch (13.00)

162

Resolution FPWD?

Publish https://w3c.github.io/did-resolution/FPWD/2024/index.html as FPWD for did-resolution?

163

DID Test Suite / Resolver Test Suite (60 min)

164

165

CBOR / CBOR-LD Representation (30 min)

166

A CBOR-based DID Document

• CBOR Advantages
• Binary, Concise, Self-Describing, Constrained Environments, Platform/Language Independent, Standardized (IETF), Deterministic (with CDE draft or dCBOR draft), compression (various drafts: cbor-packed, cbor-ld, gordian envelope )
• Disadvantages
• Is not, by-default a triple-store (needs tag registration)
• For JSON-LD-based DID Documents, i.e.�Self-Describing ≠ Context

167

What's required of this group?

• Charter has “Plain CBOR Representation” as an “Other Deliverable”
• Existing Work
• Plain CBOR Representation v1.0 (wg note 2021) https://www.w3.org/TR/did-cbor-representation/
• Problematic, based on IPFS cbor tag, no deployment
• CBOR-LD 1.0 https://json-ld.github.io/cbor-ld-spec/
• Deployed; specific to linked data

168

DID Documents as CBOR-LD

CBOR-LD performs "semantic compression" on any JSON-LD Document.

A DID Document can be a JSON-LD document, making this transformation automatic and round-trippable.

169

JSON-LD

CBOR-LD

Build Compression Dictionary

Compress

How efficient is the compression?

170

Example DID Document compression

171

Example JSON-LD did:key document containing 7 keys (1090 bytes)

{

"@context": [

"https://www.w3.org/ns/did/v1",

"https://w3id.org/security/multikey/v1"

],

"id": "did:key:z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv",

"verificationMethod": [

{

"id": "did:key:z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv#z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv",

"type": "Multikey",

"controller": "did:key:z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv",

"publicKeyMultibase": "z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv"

}

],

…

​

Example CBOR-LD did:key document containing 7 keys (534 bytes, 129 bytes if gzip'd)

D90501 // Semantic annotation: CBOR-LD (1281)

A7 // Object (7 pairs)

01 // positive integer: 1 v1.0 (compressed)

82 // Array (length 2) @context

12 // positive integer: 18 "https://www.w3.org/ns/did/v1",

1831 // positive integer: 49 "https://w3id.org/security/multikey/v1"

1867 // positive integer: 103 id

81 // Array (length 1) did:key value did:key:z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv

83 // Array (length 3)

190401 // positive integer: 1025

5822ED01F6F95ED5204FCDB05E2228763FE5DB2421AF32E13AD8F49278183892E6DC1293 // byte sequence (length 34)

1869 // positive integer: 105 verificationMethod

81 // Array (length 1) did:key:z6Mkw5LtCiW1Dn7dopLTqtcczWoBTQiBQLP6FrZeRYuvtAWv#z6Mkw5LtCiW1Dn…

83 // Array (length 3)

190401 // positive integer: did:key 1025

5822ED01F6F95ED5204FCDB05E2228763FE5DB2421AF32E13AD8F49278183892E6DC1293 // byte sequence (length 34)

5822ED01F6F95ED5204FCDB05E2228763FE5DB2421AF32E13AD8F49278183892E6DC1293 // byte sequence (length 34)

…

​

What's next for CBOR-LD?

• Establish a media type, for example:
• application/did+cbor-ld
• Not much else, it's a generalized solution
• Standards-track at W3C in the next JSON-LD WG

172

Is there demand for a “Plain CBOR Implementation”?

• i.e. not require linked data format
• If yes,
• Register appropriate new tags
• Decide on dCBOR (numeric reduction & text unicode normalization (NFC) vs CDE (simpler determinism
• Choose a compress option
• Also, an option is to adapt profile using Gordian Envelope https://datatracker.ietf.org/doc/draft-mcnally-envelope/
• Already a dCBOR triple-store, supports compression

173

174

Afternoon break (16.00)

175

Minimum Criteria for DID Method Standardization at the W3C (Manu)

176

The Controller Property (Joe)

177

Primer on Decentralization (Gabe)

178

Future proofing to support MPC based Multi-Sig e.g. FROST (Christopher)

179

New Cryptography Challenges Assumptions

• Distributed Key Generation
• Heterogeneous devices can provably create keys where only ONE device has to be honest.
• Aggregated Signatures (FROST & Musig2)
• A public key may not represent a single entity (a “node”), but instead represent an “edge”.
• A private key may never exist on a single computer
• Lots of MPC and ZKP

Resources: https://developer.blockchaincommons.com/frost/

180

Final comments

181

Final Items

• Repaying for dinner last night
• No DIDWG meetings next week - f2f recovery!
• F2F meeting?

​

182

Meeting adjourned!

183