Meeting Date & Time

Jan 23, 2025 This Task Force meets weekly every Thursday/Friday. It alternates between two times to maximize global coverage:

NA/EU Meeting: 10:00-11:00 PT / 13:00-14:00 EDT / 18:00-19:00 UTC / 19:00-20:00 CET / Friday 01:00-02:00 AEST
APAC Meeting: 14:00-15:00 PT / 17:00-18:00 EDT / 22:00-23:00 UTC / 23:00-24:00 CET / Friday 09:00-10:00 AEST

See the Calendar of ToIP Meetings for exact meeting dates, times and Zoom links.

Zoom Meeting Links / Recordings

NOTE: This Zoom meeting link will be replaced by a link to a recording of the meeting once it is available.

Attendees

@Tim Bouma

@Markus Sabadello

@Jesse Carter

@Andre Kudra

@Drummond Reed

@Scott Perry

Agenda Items and Notes (including all relevant links)

Time	Agenda Item	Lead	Notes
3 min	Start recording Welcome & antitrust notice New member introductions Agenda review	Chairs	Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role. New Members:
2 min	Review of previous action items	Leads	Link to spec: https://docs.google.com/document/d/1BVmciUxNsolRMknz3dws0dgYFfgwKLOTHRKuVb-Vazo/edit?tab=t.0#heading=h.u9t084b0ygnz
~ 5 mins	OID registration process		Move this to next meeting
~ 20 mins	Continue discussion about CA → DID relationship and implications		Tim: Replicate LetsEncrypt certificate issuance with ACME protocol Issued 4 billion certificates based on the above practice statement Browser consortium issued certificate base line requirements (find link) Wrinkle with the DIDs is the consensus on the cryptographic assurance of the DID methods. To issue an X509 to a DID it must be a registered or accepted DID methods (self certifying IDs) Only wants technical guidance in our spec The x509 world is different than the DID world, certs are static (given and revoked) which makes management difficult Drummond: Yes, per Tim’s point, I expect that software can be written to automate the setup and verification of some of the VID bridges. Markus: How does the DID reference the CERT and CERT reference to the DID What if the certificate references a specific version of the DID? Potentially include a digest of the DID rather than a version Static reference to other static reference
~ 30 mins	Review current state of spec
5 mins	Review decisions/action items Planning for next meeting	Leads

Screenshots/Diagrams (numbered for reference in notes above)

Alex:

Since X.509 systems are hierarchical, I think it will be a challenge to include a DID in the SAN of an X.509 certificate (for subordinate or leafs).
Owing to the nature of DIDs, the identifier can remain static, while the keys, services and verification relationships can all change inside
The challenge here is that while a CA might agree to including a DID in the SAN for a particular X.509 certificate, they will not have oversight of the potential changes that the subject may make to the DID over time.
This creates a governance issue whereby the content of an X.509 and a DID may be substantially different, even though they are linked via the SAN field
Therefore, in principle - while an X.509 <> DID bridge may be possible at a technical level; in practice, the governance of that DID needs to be scrutinized by the CA, which is very difficult to achieve
(All of this assumes a non-self-issued X.509)
As such, perhaps the X.509 <> DID bridge is possible in practice, but only at Root CA level, as at this level, the governance of both chains can be managed by the same governance authority.

Alternative option:

To include a DID in the SAN for a subordinate or leaf X.509 subject, perhaps the CA needs to be listed as a "controller" in the DID Document (via their own DID and linked keys) - or have their keys listed in the "authentication" section of the DID Document
If the CA is a listed controller or primary signatory on the DID Document, then perhaps this elegantly solves the potential governance issues of the DID and X.509 changing over time, since the GA needs to consent/confirm all changes or updates to the DID Document
Another option is that the DID Document only contains the X.509 of the CA in the verificationMethod/authentication sections. And the X.509 of the recipient of the CA is only embedded for a specific purpose (e.g. assertionMethod). This allows the recipient to sign credentials with their DID, but maintains the same governance structure as the X.509 hierarchy

Where does the X509 go in the DID?

Digest of the DID/URL to download the x509
Digest of DID matches digest stored in the x509
Apples and Oranges
- DID with versioning, key-rotation, etc. needs a DID method to provide a verifiable history
- x509 is a static object, makes the mapping easy from one side (DID → x509)
  - If the DID method is a SCID then doing x509 → DID is easier
2 Tuples:
- friendly name to name
- not friendly hash to hash which capture a point in time
x509s don’t support key rotation

DID → x509 Bridge:

Can we add additional specificity to the x509 cert to point to a DID that transcends the relationship to a specific key
- I.e Can we make it apply to a to DID in its entirety and not just a specific key pair
Can construct a DID url to point to a specific key within the DID document and have the x509 point to that
It feels like there are two options with the DID<->X.509 bridge: mapping key-to-key or mapping DID-to-X.509-identified-entity.

Scott:

Go from the diagram Tim created to point to the sections in the draft (enumerate it)

Why would you put any trust in something that isn’t cryptographically verifiable?

Need assurance from another place

Decisions

Sample Decision Item

Home