Time

Agenda Item

Lead

Notes

3 min

• Start recording

• Welcome & antitrust notice

• New member introductions

• Agenda review

Leads

• 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:

40 min

Continuance of discussion regarding Mathieu’s Slack message

Leads

From yesterday’s discussion and some follow-up conversations I had afterward, it seems that our main goal is to draft a recipe for bridging a DID to DNS and any x509.

This would be highly valuable and could gain momentum quickly. According to Jesse, who was a key driver behind the HA DIDs with DNS work, the technical aspect should be fairly straightforward. It’s essentially a matter of signing an identifier and placing it within the DID Doc, x509, or DNS domain. Since we’re simply providing the methodology for bridging trust realms, we are not in a position to address risk or assurance. All assurance-related processes are managed by third parties. Given this, one of the first steps we should take is to rename this task force to better reflect its purpose.

Antti: we could align the High Assurance VIDs with the wallet eAddress work in the EU: eudi-wallet-papers-and-discussions/eAddress at main · a-fox/eudi-wallet-papers-and-discussions

Tim and Jesse worked on the High Assurance DNS spec with SVIP DHS. Core problem is not from X.509, the problem with the key is having a high assurance binding with a human readable identifier and being able to resolve it to the associated cryptographic material. did:web is convenient.

Jesse: binding key pairs to an identifier with extra information. You can publish an entire X.509 cert in a DNS record. Pointing identifiers to each other is not an overall complex problem to solve.

• SAN of X.509 pointing to DID

• X.509 key being used as a verificationMethod or Controller in a DID

DHS trust architecture: Trust Architecture | DHS Technical Implementation Requirements for Decentralized Identity

Open

Draft RFC to be moved through IETF governance (need to decide which WG is best fit)

Tim: What does it mean to have “Digital Sovereignty” - is an emergic theme in global markets

Scott: Larger issue is ecosystems are launching global PKI models that aren’t going to go away. We need to create a path for Certification Authorities to have a future for their business. They can be issuers, but perhaps not a trust anchor. Need to accommodate for the CA Browser Forum.

Drummond: Larger pattern on bridging identifier schemes is possibly the most powerful thing we can work on. NOT a goal to address human readability.

Andre: traversibility between the trust realms is the most important thing here. We may also be able to achieve human readability through bringing in LEIs as well

Drummond: As we explore the power of trust registries, we need to establish that a trust registry is the right trust registry. We may simply require that a GAN trust registry has a High Assurance VID. If we describe technically what needs to happen to bridge the main four domains, then by that point we may have fifth. We don’t have to take any stance in terms of which combintations of the bridges creates the highest assurance, we can simply provide best practices on how to connect the different trust domains. GAN can then provide a profile for what they recognise, which other ecosystem’s can follow or remix.

Scott: What we might be really talking about is a “minimum level of assurance” that meets the goals of more global acceptance for a purpose, set of requirements and context.

Jesse: We need to qualify what we mean by “high assurance” because there are different levels of high assurance in practice. Its quite a broad and loaded term.

Drummond: Difference between “accurate” naming and naming for “marketing” purposes is important as well. Should the spec say that there is a minimum level to qualify as a high assurance VID? Its a slippery slope, rather than just explaining how to build the different bridges

15 min

Next steps

Leads

Jesse: Spin up a DID and see which ways an X.509 can connect with them.

Encode the X.509 as a JWK as a verificationMethod. If that becomes signed via a DI proof, then you have multiple layers of verification - especially if that then goes into a DNS record.

Bottom line is that there’s lots of ways this could work and the cryptography isn’t overly complicated.

Drummond: This HAS to be interoperable, which is why this is such an important spec

Markus: Putting JWKs into verification methods has already been done, there’s also an opportunity with W3C DID WG to build this into DID Core, DID Resolution and this side of the “bridge”.

Drummond: Let’s take this to slack to tackle the details - lets get this started

15 min

Allocation of sections for attendees to work on

Leads

10 mins

Decision to be made on timelines for IIW announcement

Leads

5 mins

Decision to be made on cadence of meetings going forward

Leads

5 mins

• Review decisions/action items

• Planning for next meeting 

Leads