Skip to content

Latest commit

 

History

History
483 lines (418 loc) · 37.1 KB

agenda.md

File metadata and controls

483 lines (418 loc) · 37.1 KB
Raw

did:webvh DID Method Work Item Rolling Agenda

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

Agenda: HackMD, did:webvh 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:webvh log format with other DID Methods
  • Merging did:webvh features into did:web?
  • Implementor's experiences -- architectures, learnings
  • A did:webvh test suite -- such as proposed here

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

Meeting - 19 Dec 2024

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

Recording: Zoom Recording and Chat Transcript

To Do's from Meeting (as generated by Zoom):

  1. All participants to review the latest PR for v0.5 of the did:webvh specification.
  2. DONE Commit Stephen to add a commit to the PR clarifying that null and an empty list both mean no pre-rotation for the next_key_hashes parameter.
  3. Stephen to finalize and declare v0.5 of the specification after the PR is merged.
  4. Dmitri to find and share external specs related to key security events.
  5. DONE Issue Brian to create an issue about addressing right to deletion requests in the specification.
  6. Andrew to continue work on the resolver, including handling witness rules and improving caching behavior.
  7. All participants to join the did:webvh channel on the DIF Slack instance for future discussions.

Attendees:

  • Stephen Curran
  • Brian Richter
  • Andrew Whitehead
  • Patrick St. Louis
  • Kaliya Young
  • Emiliano Sune
  • Rob Aaron
  • Andor Kesselman
  • Keith Kowal
  • Dmitri Zagidulin
  • Markus Sabadello

Agenda and Notes

  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 [email protected].
    3. [did:webvh Specification license] -- W3C Mode
    4. Introductions and Agenda Topics
      1. Welcome to Andor
    5. Announcements:
      1. NEW DIF Slack channel did-webvh (link) -- will invite everyone to the Slack instance and channel.
  2. Are we good with the next version of the specification for publication?
    1. DID Method name is updated.
    2. Pre-rotation change is made (although we will add a picture to clarify).
      1. PR -- allowing turning off pre-rotation, and how.
      2. Next PR: Add the picture from Brian and flow from Sylvain to spec or info site.
    3. Witness proofs in a separate file.
      1. PR: JSON fixed.
      2. PR: Sign the versionId instead of the DID Log Entry
    4. Any more changes?
      1. NOT DISCUSSED Should we back off/deemphasize/remove the portability capability?
  3. Discussions left open from last week.
    1. Should a key from a prior log entry be used to verify a signature? YES! -- Related to that -- should a did:webvh resolver provide any support for doing that?
      1. The DID Controller should be able to express that a key is revoked. Ideally for signing, but also for verifying -- we need a status. But that should be a DID Core feature -- did:webvh would do what the DID Core spec. says to do.
        1. Andrew -- we don't need to solve this ourselves.
        2. Markus -- use query args and fragment or keep the keys in the latest DID Document.
        3. Dmitri -- agree that all DID Methods should deal with.
          1. Current did:web differentiates between expiring and deleting keys.
          2. Not obvious in DI cryptosuite or DID Core specs -- can have date in DI.
          3. OpenID Federation -- JWK Sets (JWKS) added optional property "revoked": "<timestamp>" and "revoked_reason": "<enumeration>" -- we should have valid from/to and enumerated reason (e.g. "rotated" "compromised").
          4. Suggest investigating the idea and share at DID Core level
          5. Suggest including the three pieces of information (from, to, reason); using the log vs. the DIDDoc to store the data. For more flexibility -- perhaps use a key security event and store it in the log (look at external specs -- Dmitri to find/point out).
          6. For DID Methods that can't keep history -- issuer registries might be a place to go.
      2. Should a resolver return the entire log, so that a client can weed through it?
        1. Markus: Not a way to get the entire log. Look to the DID metadata as a way to use that. Other DID Methods have used this and might give us guidance. DID Resolution result -- the DIDDoc + DID Metadata. Examples: did:indy returns its "state proofs" as metadata.
      3. Should a resolver resolve a fragment that is not in the current DIDDoc? For example, if the VC is signed by an identified key (e.g., <did>#key-a), can the client ask the resolver for that key regardless of the version of the DIDDoc it is in? What if it is in multiple versions of the DIDDoc? Presumably all are the same, but...
        1. Current answer NO -- this is not supported with DIDs.
        2. However, this topic is being discussed at the DID Working Group --- fragment handling rules. Perhaps this could be supported. Raise the issue there.
      4. A DID URL of the form <did>?versionId=<versionId>#key-1 could be used. A resolver MUST resolve that.
      5. did:webvh VersionIDs are of the form "3-1241ge6wgd" (<vernum>=<entryHash>). Given that, can we do a query in the form <did>?versionId=3?
        1. Brian says no
        2. Patrick says hey, that's useful! -- but later takes it back
        3. Markus there is no support for this in DID Core -- also, with metadata you can findout the prevVersionId (but Andrew checked and there is only nextVersionId -- which is not helpful to us).
        4. Andrew says we should use the short form, or perhaps invent another parameter (which, it turns out, we already have -- see below).
        5. Andrew -- separate point -- what if both a versionId and versionTime parameter -- we must reject if not consistent -- add this as a clarification?
        6. Brian -- maybe we rethink versionId format? -- NO!!!
        7. Patrick -- does versionId need to be in the DIDDoc to use the versionId query parameter? Markus says No (phewww!!!) it shouldn't be in the DIDDoc
        8. Brian/Stephen - we have in the spec (v0.5) to use the form ?versionNumber=3 -- e.g. inventing a new query parameter. Everyone was more or less happy with that.
      6. VersionTime can always be used.
      7. Should there be a way to get a list of all keys in all the versions of the DIDDoc, in case the client wants to try them all? NO. Use DID metadata and other techniques to get / resolve the DID versions.
      8. Other approaches? No suggestions.
    2. Resolved -- PR ready: Should the addition of witnesses only be permitted in the first entry or can it be later? As defined in the latest update, later is permitted. Decsion: Leave as is.
    3. Resolved -- PR added: Is there a use case for turning off witnessing? As defined now, this is not mentioned, but presumably one could put an empty list ([]) in and "turn off" further witnessing -- although that update would have to be witnessed. Decision: Add in a paragraph about turning off witnessing.
  4. Status Check: Updating the implementations to the new version. Goal is to try for backwards compatibility -- but not to go to extremes. Please report back on the challenges.
  5. Are we ready to declare with the current PR that v0.5 is complete? Are there any other changes we want to see?
    1. Minor addition, but otherwise all agreed we are ready. Tweak: For nextKeyHashes and updateKeys -- empty list or null are permitted. Currently only have [].
  6. NOT DISCUSSED: CEL proposal announced by Manu. I don't think we can use the spec directly, and it would complicate the explanations about what is in that spec, and what is in the did:webvh spec. Thoughts? There are some really useful ideas -- such as the ability to break logs into multiple files -- although we would want them in reverse from that they have defined.
  7. NOT DISCUSSED: Plans for updates to the spec.
    1. A ChatGPT pass, likely using the using the "Academic Assistant Pro" GPT. That should include DRYing the spec to remove duplication.
    2. Cleaning up [[spec]] references -- Brian has enabled us to add our own spec references.
    3. Security and Privacy sections. Anyone able to help?
    4. Getting "spec to a standard" advice and applying those changes.
  8. NOT DISCUSSED: AnonCreds object formats and did:tdw, and perhaps a follow up discussion on DID Linked Resources. @andrewwhitehead has provided this proposal. Let's talk about it.
  9. NOT DISCUSSED: DIDDoc and DID Metadata
  10. NOT DISCUSSED: Spec. PRs and Issues
  11. NOT DISCUSSED: Update on the did:webvh Web Server -- Patrick St. Louis.

Meeting - 05 Dec 2024

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

Recording: Zoom Recording and Chat Transcript

Attendees:

  • Stephen Curran
  • Brian Richter
  • Andrew Whitehead
  • Patrick St. Louis
  • Kaliya Young
  • Jamie Hale
  • Alex Sinelnikov
  • Emiliano Sune
  • Rob Aaron
  • 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 [email protected].
    3. did:tdw Specification license -- W3C Mode
    4. Introductions and Agenda Topics
      1. Kaliya and Alex
    5. Announcements:
      1. Much of the renaming of the DID Method has been completed. Next up is the update of the implementations.
  2. Are we good with the next version?
    1. Name is updated.
    2. Pre-rotation change is made (although we will add a picture to clarify). 3. Issue -- should we allow turning off pre-rotation, and how. Issue 151 4. Add the picture from Brian and flow from Sylvain to spec or info site.
    3. Witness proofs in a separate file. 5. Brian to fix the JSON. 6. Sign the versionId instead of the DID Log Entry -- Issue 152
  3. Discussions left open from last week.
    1. Should a key from a prior log entry be used to verify a signature? YES! -- Related to that -- should a did:webvh resolver provide any support for doing that?
      1. The DID Controller should be able to express that a key is revoked. Ideally for signing, but also for verifying -- need a status. But that should be a DID Core feature -- did:webhv would do what the DID Core spec.
      2. Should a resolver return the entire log, so that a client can weed through it? YES
      3. Should a resolver resolve a fragment that is not in the current DIDDoc? For example, if the VC is signed by an identified key (e.g., <did>#key-a), can the client ask the resolver for that key regardless of the version of the DIDDoc it is in? What if it is in multiple versions of the DIDDoc? Presumably all are the same, but... YES (we should discuss in an issue)
      4. VersionTime can always be used.
      5. Should there be a way to get a list of all keys in all the versions of the DIDDoc, in case the client wants to try them all? NO
      6. Other approaches?
    2. Should the addition of witnesses only be permitted in the first entry or can it be later? As defined in the latest update, later is permitted. Decsion: Leave as is.
    3. Is there a use case for turning off witnessing? As defined now, this is not mentioned, but presumably one could put an empty list ([]) in and "turn off" further witnessing -- although that update would have to be witnessed. Decision: Add in a paragraph about turning off witnessing.
  4. Next efforts -- updating the implementations to the new version. Goal is to try for backwards compatibility -- but not to go to extremes. Please report back on the challenges.
  5. NOT DISCUSSED: AnonCreds object formats and did:tdw, and perhaps a follow up discussion on DID Linked Resources. @andrewwhitehead has provided this proposal. Let's talk about it.
  6. Plans for updates to the spec.
    1. A ChatGPT pass, likely using the using the "Academic Assistant Pro" GPT. That should include DRYing the spec to remove duplication.
    2. Cleaning up [[spec]] references -- Brian has enabled us to add our own spec references.
    3. Security and Privacy sections. Anyone able to help?
    4. Getting "spec to a standard" advice and applying those changes.
  7. NOT DISCUSSED: DIDDoc and DID Metadata
  8. NOT DISCUSSED: Spec. PRs and Issues
  9. NOT DISCUSSED: Update on the did:webvh Web Server -- Patrick St. Louis.

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 [email protected].
    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 [email protected].
    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 [email protected].
    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 [email protected].
    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 [email protected].
    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 [email protected].
    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.