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

2 min

Update main diagram

Link:

Drummond: Reference the Lei to x509 relationship

~ 30 mins

Review current state of spec AND updates made by Alex & Jesse

x509 and DID bridge

Hash of DIDs as ID in X509:

• Tim: Hash of DID for identifier in x509

• Markus: Hashlink DID:CORE

x509 must relate to a keypair Controlled by the DID Doc:

• Drummond: Potential link between x509 to the DID beyond a keypair

• Markus: How doe

• Tim: Public Key of x509 is idempotent (static). x509 doesn’t support key rotation.

  • DIDs are not idempotent (non static)

  • DNS idempotent (non static)

  • Use outputs of the governance

    • Need to specify the rules the mapping needs to abide by

    • Criteria for managing the bridge

• Drummond: Diff between static and non static (DID vs x509) equivalence assertion than the original assumption:

  • CA certifying the DID/Controller and issuing a cert against that DID

  • Certificate Practice Statement around doing that issuance to a DID is a different thing than the technical bridge (example limits on revocation periods, certificate renewal)

  • Has value because this continuity can be maintained between the rotating DID and x509 certificate

• Scott:

  • You can change keys within an x509: rekeying the certificate but are fixed within the certificate lifetime

  • CAs are a signing authority to a public key included in a CSR (don’t generally get involved in keys)

  • CAs endorse the meta data in the CSR

    • Can request modification and rekeying the certificate within the Certificate Validity Period

  • We should create a Certificate Policy/Practice statement

  • We should assign ourself an OID?

  • How do CAs subscribe to the CP?

    • Remote Attestation (IETF RATS) for verifying the DID

    • This could be extended for a DID

  • Can involve a public CA in this process

  • OIDs are driven by usecases

  • 2 Trust Lists (Soon to be released)

    • Issue = Endorsing a CSR

    • CA cannot issue a certificate unless that Subject Name is in a Trust List

• Tim:

  • Is there an OID for the domain name being in the CN?

    • How do we mirror this for DIDs

  • We want to resolve to a DID, where does that live in the certificate?

    • The CA needs to do some challenge and response and that needs to be included in the CP to verify control of the DID

  • Need to agree on the recipe which is tentatively:

    • Put the DID in the SAN, may use a hashlink, maybe use the Common Name (see what vLEI)

    • The keypair used to generate the CSR and rekey the x509 needs to be present in the DID document as a verificationMethod.

    • Before thou issue the x509 need to do a challenge and response with the DID using the keypair pertaining to the x509.

• Markus:

  • The keypair used to sign the CSR should be a public key in the DID document

  • Does it matter what verification relationship is used for this

• Scott:

  • Don’t add something new. Minimal changes is the goal.

  • DID Cert?

5 mins

• Assign homework for attendees to fill out sections in more detail using the “cryptographic bridge” and “non-cryptographic bridge” structure