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:

20 min

Review of previous action items

Chairs

- Standardised pointer structure: As we go through the exercise of putting the initial MVP identifiers together, it will hopefully expose an underlying pattern of structure which we can then use to build out a model that we can share with other ecosystems

- Proposed idea, start with a “Minimum viable” set of identifiers - DIDs, X.509 and DNS which then we can iterate out from afterwards
- work assignments to achieve first draft

10 mins

Open discussion points from previous NA/EU meeting

All

How should we structure the spec and break up the work? How long should we give ourselves (realistically) to have a full Working Draft?

• DID to DNS

• DNS to DID

• X.509 to DID

• DID to X.509

• DNS to X.509

• X.509 to DNS

@Tim Bouma :

• From Root to Resource

• Technical side should be very simple

• How do you traverse from governance ecosystem A to governance ecosystem B? This is likely out of scope.

@Drummond Reed :

• We should point to ISO spec about including vLEI in X.509 cert

• How much governance and how do we want to approach it? Three options

  • 1. Technical requirements with a governance consideration

  • 2. Section of the spec generally on governance considerations

  • 3. Governance is going to be a separate document

@Alex Tweeddale :

• Could we have a pointer to governance frameworks, rather than a full consideration of the governance frameworks between ecosystem A and B?

@Tim Bouma : Root to record, record to root:

• Mapping from a non-cryptographic identifier to a cryptographic identifier:

• When you are dealing with non-cryptographic identifier (e.g. DNS record), the question is how do you make sure that is legitimate (DNSSEC)

• Root to Record

  • Cryptographic to non-cryptographic

  • Public key with corresponding private key

  • Public key can generate a signature and sign a record, saying e.g. this domain name is mine, and I will assign it a fixed signature

  • If you know the public key, you can look up that record and see that it is signed by that public key

• Record to Root

  • Non-Cryptographic to cryptographic

  • http://Example.com has no way to sign that it actually owns that public key, this is where you need to rely on

    • Proper authentication and management to say that you own that public key

    • Challenge response mechanism

    • If that public key signs my record back, that gives assurance

@Jesse Carter

• Importance of bi-directional binding

• We have to consider where do we put the bi-directional relationship, and how do we validate / ensure that the bi-directional relationship is being honoured

15 mins

Assignment of work items for spec first draft

All

@Scott Perry

• Registered OID

• Isn’t supposed to be extended key usage (but can use other X.509 extensions)

• Found a place to tie the OID to the identifier

@Tim Bouma

• Domain name will be in the “common name” of X.509

10 mins

Other topics

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs