Skip to content

Latest commit

 

History

History
329 lines (279 loc) · 23.9 KB

agenda.md

File metadata and controls

329 lines (279 loc) · 23.9 KB
Raw

Trust DID Web Work Item Rolling Agenda

Zoom Link: https://us02web.zoom.us/j/83119969275?pwd=IZTuXgGLtdLPjPLuB6q8zHXazxHSsU.1

Agenda: HackMD, TrustDIDWeb Repository (synchronized after each meeting)

WG projects | DIF page | Mailing list and Wiki | Meeting recordings

Table of Contents

Meeting Information

Participants are encouraged to turn your video on. This is a good way to build rapport across the contributor community.

This document is live-edited DURING each call, and stable/authoritative copies live on our github repo under /agenda.md, link: Agenda.

Future Topics

  • Using the did:tdw log format with other DID Methods
  • Merging did:tdw features into did:web?
  • Implementor's experiences -- architectures, learnings
  • A did:tdw test suite -- such as proposed here

============================================

Meeting - 21 Nov 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording and Chat Transcript

Attendees:

  • Stephen Curran
  • Sylvain Martel
  • John Jordan
  • Patrick St. Louis
  • Andrew Whitehead
  • Brian Richter
  • Emiliano Sune
  • Martina Kolpondinos
  • Michael Herman
  • Michel Sahli
  • Rob Aaron
  • Dmitri Zagidulin
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
    5. Announcements:
      1. Add here...
  2. DID Method Name Change:
    1. What's the new DID Method name going to be? Leaning is towards did:webl. Let's discuss.
      1. Too easy to confuse with did:web1.
      2. Or perhaps we should use it instead of did:webl.
    2. An idea -- did:web:<something> but that doesn't sound aligned with the DID spec and would break the name space and did:web spec. Nope.
    3. did:weblog -- but that conflicts with blog.
    4. did:webh -- "h" for history, emphasizing the log (history) capability, which is the important part. Loses the "secure", but so be it.
    5. did:webhash as an alternative. Although it is bit subtle a connection to the purpose of the DID Method.
  3. Version 0.5 Updates:
    1. Pre-rotation change -- PR #129. Summary:
      1. No pre-rotation:
        1. Each entry is signed by a key from the active updateKeys list.
        2. The active list is the most recently defined list prior to the current log entry -- except for the first entry, where it is the list in the first entry.
      2. With pre-rotation:
        1. Eliminate the prerotation parameter. Preroation is automatically activated when the nextKeys item is present in a DID log entry and MUST be enforced from then on.
        2. Can be activated in the first log entry, or afterwards. If activated afterwards, the current log entry is signed according to the "non-pre-rotation" rules, and the pre-rotation rules apply to all subsequent log entries.
        3. Once active, every entry MUST have a new updateKeys and nextKeys list.
        4. The hash of each updateKeys list item MUST be in the nextKeys list from the previous entry. This rule does not apply to the first log entry, as there is no previous entry.
        5. Each entry must be signed (in the DI proof) by a key in the updateKeys list from the current record.
    2. Witness change requests from @andrewwhitehead HackMD Doc. Summary:
      1. Data model for the witnesses parameter remains the same (list of witnesses, threshold).
      2. Instead of the witness proofs going into the log, they are stored in a separate file, witness.json -- an array of proofs from witness, including the DID Log entry version number (1, 2, ...) to which the proof applies. Or should it be the version_id?
      3. The array contains only the last two proofs from each witness from which proofs are collected. When a witness proof is retrieved, if there are already two in the file from the witness, remove the oldest, and add the new one before writing the file.
      4. The processing is: Given an entry to be witnessed, verify that the witness.json file contains valid witness proofs from a threshold of current witnesses on the current or newer log entries.
      5. Questions from the document:
        1. Witness proofs can be published before the DID log with a new log entry is published. This eliminates the race condition of the DID Log being published without corresponding witness proofs. The "two proofs" per witness allows for the verification of at least one of the proofs of the witness when the witness.json is published before the corresponding log entry. The resolver would ignore the proof of an unpublished entry.
        2. What DID Method can a witness use? Currently must be did:webh, but could/should we allow did:key be used? Could use "instantly resolved DIDs" -- e.g. did:key. Short list: did:webh, did:key, did:jwk, maybe did:web.
          1. Long discussion resulted -- to be fully resolved in Discord and at the next meeting.
          2. It was proposed that there are two use cases for witnesses, one where there was just the added security of needing more than one key to sign the log entry (e.g. must compromize multiple keys and the web server to impact the DID), and another where the reputation of the witness was important in an ecosystem (external parties monitoring the behaviour of the DID Controller), so there needs to be ways to attach reputation (presumably, via VCs or a Trust Registry) to the witness.
          3. For the first - purely for added security - an ephemeral key method is sufficient -- did:key. We discussed also allowing did:jwk but it was felt that was just an alternative to did:key that adds complexity/dependencies to the spec without adding any value.
          4. For the second, the reputation could be added by a Trust Registry while using did:key, but it would eliminate (complicate?) the ability to use VCs for the reputation.
          5. For the second, some thought support for did:webh makes sense, while others are concerned about possiblity of resolution taking a long time if the witnesses have witnesses have witnesses, and so on. Worse is the scenario of DIDs having common witnesses, and the need to detect and handle an infinite loop.
          6. This then changed to a discussion, that also needs to be continued on Discord and at the next meeting about if a key from a prior log entry should be used to verify a signature in the did:webh scenario, and more broadly in the use of verifiable credentials signed using a key in a did:webh DIDDoc.
        3. NOT DISCUSSED: Should the addition of witnesses only be permitted in the first entry?
        4. NOT DISCUSSED: Is there a use case for turning off witnessing?
  4. NOT DISCUSSED: No progress made on the spec. Latest spec updates and implementation notes.
    1. Cleaning up [[spec]] references -- Brian has enabled us to add our own spec references.
    2. Next up -- DRYing the. spec.
    3. Security and Privacy sections. Anyone able to help?
    4. Getting "spec to a standard" advice and applying those changes.
  5. NOT DISCUSSED: DIDDoc and DID Metadata
  6. NOT DISCUSSED: Spec. PRs and Issues
  7. NOT DISCUSSED: Update on the did:tdw Web Server -- Patrick St. Louis.
  8. NOT DISCUSSED: Update: AnonCreds object formats and did:tdw, and perhaps a follow up discussion on DID Linked Resources
    1. Good discussion about the pros and cons of signing the resource, if it is signed should we use the VCDM or just attach a Data Integrity proof, and how we can get a consistent hash and where should it go.
    2. Alignment with the DID Linked Resources spec would really nice to have. We don't want to return in the DIDDoc metadata the information about all the resources associated with a DID -- it can be a lot of data. That said, a discovery mechanism for resources, such as <did>?resources would be really nice.
    3. The next step is to create a document about a likely approach (@andrewwhitehead agreed to create that first draft) and then we can then collaborate on implementing/updating the document from there.

Meeting - 07 Nov 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording

Attendees:

  • Stephen Curran
  • Patrick St. Louis
  • Andrew Whitehead
  • Brian Richter
  • Cole Davis
  • Emiliano Sune
  • Kjetil Hustveit
  • Martina Kolpondinos
  • Michael Herman
  • Michel Sahli
  • Rob Aaron
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
      1. Pre-rotation change to be put into a PR for discussion -- Michel Sahli
    5. Announcements:
      1. DID Methods Working Group Meetings start next Wednesday, Nov. 13 at 9:00 Pacific / 18:00 Central Europe -- calendar.
  2. IIW Update
    1. did:tdw session
    2. <did>/whois as a separate specification and work item.
    3. Getting <did>/whois examples into the wild -- resolver support, did:tdw Server support.
  3. No progress made on this. Latest spec updates and implementation notes.
    1. Cleaning up [[spec]] references -- Brian has enabled us to add our own spec references.
    2. Next up -- DRYing the. spec.
    3. Security and Privacy sections. Anyone able to help?
    4. Getting "spec to a standard" advice and applying those changes.
  4. Registering did:tdw as a DID Method PR, and [DONE!] adding a did:tdw component to the Universal Resolver (thanks Brian!).
  5. Spec. PRs and Issues
  6. Update on the did:tdw Web Server -- Patrick St. Louis.
  7. AnonCreds object formats and did:tdw, and perhaps a follow up discussion on DID Linked Resources
    1. Good discussion about the pros and cons of signing the resource, if it is signed should we use the VCDM or just attach a Data Integrity proof, and how we can get a consistent hash and where should it go.
    2. Alignment with the DID Linked Resources spec would really nice to have. We don't want to return in the DIDDoc metadata the information about all the resources associated with a DID -- it can be a lot of data. That said, a discovery mechanism for resources, such as <did>?resources would be really nice.
    3. The next step is to create a document about a likely approach (@andrewwhitehead agreed to create that first draft) and then we can then collaborate on implementing/updating the document from there.
  8. DID Portability
    1. Reviewed the spec concept
  9. Potential conflict on the name "tdw"
    1. Project called "Trusted Digital Web" which has used the "TDW" acronym, although not for a DID Method. The project does mention DIDs. How to address the potential conflict? Michael Herman raised an objection on the DID Registration PR that we submitted.

Meeting - 24 Oct 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording Link

Attendees:

  • Stephen Curran
  • And others...
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
  2. Latest spec updates and implementation notes.
    1. Cleaning up [[spec]] references -- Brian has enabled us to add our own spec references.
    2. Next up -- DRYing the. spec.
    3. Security and Privacy sections. Anyone able to help?
    4. Getting "spec to a standard" advice and applying those changes.
  3. Registering did:tdw as a DID Method PR, and adding a did:tdw component to the Universal Resolver.
  4. DID Linked Resources and did:tdw
    1. Mechanisms to publish/resolve files related to the DID -- e.g., AnonCreds objects, OCA Files, BitListStatus, etc.
    2. DID Linked Resources vs. relativeRef currently in the spec
    3. Complexity of DID Linked Resources is that the DLRs must be listed somewhere so they can be included in the DID Metadata that is part of the DID resolution result. 4. Use case: Clients of resolvers find a DID URL for the resources. With relativeRef there is the same DID-To-HTTPS transformation to get the resource as to get the DID Log/DID Doc. 5. Use case: A resource points to a sequence of related documents, as in the case of RevRegEntries in AnonCreds. One identifier, but multiple resources. How does one find (a) the latest, (b) the entire list of entries (c) a specific entry at a given time? Each of those features could be needed with RevRegEntries.
  5. Spec. PRs and Issues
    1. Issues that would be breaking changes -- close them?
  6. Update on the did:tdw Web Server -- Patrick St. Louis.
  7. Open Discussion

Meeting - 10 Oct 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording Link

Attendees:

  • Stephen Curran
  • Sylvain Martel
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
  2. Latest spec updates and implementation notes.
    1. Version 0.4 is out.
    2. https://didtdw.org/ site is published.
    3. Implementer's Guide, etc. removed from the spec
    4. Next up -- DRYing the. spec.
    5. Anyone know a "Spec Veteran" that would be willing to review and point out deficiencies and potential improvements in the spec? Especially one with W3C spec experience.
      1. Suggestion to wait on this until after the DRYing is done.
  3. Update on the did:tdw Web Server -- Patrick St. Louis.
  4. DID Linked Resources and did:tdw
    1. Should we? How?
  5. Spec. PRs and Issues
  6. Open Discussion

Meeting - 26 Sept 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording Link

Attendees:

  • Stephen Curran
  • Others...
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
  2. Feedback from implementing did:tdw Witness capability -- Brian Richter.
    1. Resolver has a /witness endpoint -- got the request from the DID Controller.
    2. Stuck on signing the entry. Both log entries have a did:key -- the witnesses must be published DIDs -- SHOULD be a did:tdw?
    3. Where to send the witness request? The DID Controller should know that.
    4. Perhaps add an endpoint for the witnesses in the witnesses object? Decided no -- not to include the endpoint since that puts too much definition in the specification on how to implement the DID Controller and Witness interface. It is left to the DID Controller and witnesses to decide how they will interact. All that is specified is that resolvers can verify the proofs via the DID referenced in the witnesses object, and the key identifier that references that DID in the proof itself.
    5. Use cases for witnesses -- (1) monitoring the DID controller to prevent maliciousness -- no backtracking, (2) preventing attacks on the DID Controller.
    6. Next steps -- Brian to continue implementing based on the discussion. Addition of weasel words to the spec to note the implementation challenges.
  3. Spec. update to switch from a DID log entry being a JSON array to an object. Feedback? -- Stephen Curran. Good to go with the names of the items in the object.
    1. General feedback -- all good.
    2. We reviewed the names and agreed with the ones in the PR now -- versionId, versionTime (both of which align with the DID Core spec query parameters), parameters, and state. proof is as defined in the DI specification.
  4. Proof Chain vs. Proof Set
    1. Semantics:
      1. Proof Chain implies that that a subsequent signature is added to an existing signature, implying an attestation of that signature. But there are no implementations of it that we know of, and it's inclusion adds complexity without the semantics giving much benefit in did:tdw.
      2. Proof sets are just independent proofs across the same data.
    2. For now, let's just go with proof sets, as there is little benefit from using proof chains.
  5. Update on the did:tdw Web Server -- Patrick St. Louis. 8. Demo given, but we ran out of time.
  6. DID Linked Resources and did:tdw
    1. Should we?
  7. Spec. PRs and Issues
  8. Open Discussion

Meeting - 12 Sept 2024

Time: 9:00 Pacific / 18:00 Central Europe

Recording: Zoom Recording Link

Attendees:

  • Stephen Curran
  • Dmitri Zagidulin
  • Cole Davis
  • Brian Richter
  • Andrew Whitehead
  • Sylvain Martel
  • Martina Kolpondinos
  • John Jordan
  • Patrick St. Louis
  • Jamie Hale
  1. Welcome and Adminstrivia
    1. Recording on?
    2. Please make sure you: join DIF, sign the WG Charter, and follow the DIF Code of Conduct. Questions? Please contact operations@identity.foundation.
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
  2. Introduction to the did:tdw Work Item at DIF
    1. CCG Presentation on did:tdw (starts at the 5:40 mark of recording)
  3. Brief(!) introduction to did:tdw
  4. Discussion:
    1. What do you want this group to achieve?
    2. What would help you the most?
      1. Get to 1.0!
      2. Web server
      3. Next step topics -- witnesses, deactivation -- how does a diploma remain verifiable when the isssuer disappears -- with their web server. Aka durability.
      4. Acceptance of the method broadly.
      5. How did:tdw compares with KERI.
      6. Test suite!!!!! Implementation consistency.
      7. Cryptographic audit on the techniques used -- hashing use, etc.
      8. Governemnt acceptance of the cryptographic suites being used.
      9. Switchcord is running live use cases based on did:web -- would like to transition to did:tdw and its features.
  5. Feature list feedback document -- importance of features?
  6. Future Topics
  7. Next Meeting -- next week, same time
    1. Input to TPAC.
  8. Spec. PRs and Issues
  9. Action items and next steps:
    1. Stephen to create a PR to change the spec. to say that a version is an object, JSON Patch is no longer used, and that the Data Integrity Proof is across the version object, without a challenge.
    2. Everyone to look at the list of did:tdw features and comment on the features.
    3. Everyone to review issues and open others as needed, to drive future discussions.