| Time | Agenda Item | Lead | Notes |
| 5 min | - Start recording
- Welcome & antitrust notice
- Introduction of new members
- 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:
|
| 5 mins | Review of action items from previous meeting | Chairs | - This will be our second meeting
|
| 5 mins | Announcements | TF Leads | News or events of interest to members5 mins | Reports | Open | | - This is a provisional WG/TF and we hope to be officially under ToIP in September 2023
Current work - Spec repo to be donated to ToIP if WG/TF is approved
| Reference impl will be continued - Previous reference impl was started here
| Artifacts of previous work
Phils hackmd has been included in the spec and no longer should be used. Comments will be moved to issues.
| 5 mins | Review of action items from previous meeting | Chairs | - Markus Sabadello will move Phil hackmd comments to the Github repo as issues or discussions
- Daniel Hardman will donate his dh1128 repo if ToIP will allow.... all commits are signed
- Lance Byrd will provide an outline of how to use a TEL to verify the signature document
|
| 5 mins | Announcements | TF Leads | 5 mins | Any other business | Open | News or events of interest to members: - This is a provisional WG/TF and we hope to be officially under ToIP in September 2023
- Change meeting time to better accomodate west coast (times after 10am ET)?
hackmd.io/@u54fb76oTJW272B17r4YPg/HJfCB_S92Previous reference implementationgithub.com/WebOfTrust/did-keri-resolver |
| 25 mins | Discussion | Open | - Will there be two specs, one for did:webs and did:keri?
- did:webs will be most convenient and will certainly move ahead
- depends on the web, so it is a narrower scope
- perhaps from the 'did method' point-of-view, this is all that is necessary? keri can just be keri without dids
- keri has no dependency on web tech, could be bluetooth
- this method would be wider to encompass all that keri can do
- useful when paired with didcomm, well beyond web tech
- Here is some follow-on information from the keri-dev meeting from Sam Smith :
- KEL watcher exists in the KERI ecosystem. TEL watching is still being defined since there are different types of TELs with different security properties.
- The core concept is duplicity detection. So we need to explore the ways a TEL could be prevent verifiable duplication.
- In terms of the did doc and did KEL being co-located:
- If you completely control the AID and ecosystem then no need for a watcher
- You could even statically generate the KEL and JSON and publish them
- In a more complex environment you would leverage the entire KERI ecosystem
- The did:webs resolver could reach out to its own watcher
- For the reference implementation the did:webs document generation service and KEL/TEL service will live together
- TLS should not be used for authentication, only used for confidentiality
- Markus Sabadello , Stephen Curran , and Lance Byrd diagrams to pompt discussion for the ecosystem/architecture and reference impl
 Image Removed- resolver is the did:webs verification client
- the did doc service and resolver will BOTH leverage keri libs
- we must comply with did:web and did:webs security requirements?
- maybe did:web can be optional, so you MIGHT be resolvable as did:web IF you comply
- Should did kel and did json be resolvable on the same path?
- Github as a did:webs platform
- Actions that publish the kel and json in the same folder.
- KEL/TEL service is essentially a witness/watcher service
- The url where the did:webs is published helps you locate the KEL
- witness is a primary KEL copy
- watcher is a secondary KEL copy
- Given an OOBI (the witness url and AID) you pass the witness an AID and are given the KEL
- KELs and TELs can grow large, do we need to consider this size?
- In terms of key rotations and DID doc history Philip Feairheller and Drummond Reed discussed a DID doc URL parameter and registering a DID doc extension for easily referencing the key state used for VP, etc.... and defining how that resulting JSON or array will look.
- What is a TEL and how does it fit in a did doc
- Transaction event log
- Set of actions taken with your keys, that are anchored to a key state. So you know if something happened before or after a key state
- For instance issuing a credential. You can prove the key state when you issued the credential
- Many did docs fail to track the key state when you act (issue a credential)
- Can be used for publishing service endpoints
- Will other documents be tied to the did document.... if you only know W3C VCs then how do you 'walk' the history without knowing keri?
- For instance issuing AnonCreds credentials, can we use the verifiability of keri to show the issuance, but all from the did doc (without knowing keri TELs)
- Everyone will be using keri to produce the did doc, maintain keys, etc.
- Are there keri operations that non-keri aware users will never use?
|
- IIW October 2023
- Do we want to define milestones, like IIW, for the spec and reference impl?
- Arrive with a coherent draft, already registered in DID registry
- Also arrive with reference impl in DIF Universal Resolver
- DIF identifiers discovery
- did:plc discussion
|
| 5 mins | Reports | Open | - Lots of progress/conversation, issues, PRs in github and slack
|
| 25 mins | Discussion | Open | |
| 5 mins | Any other business | Open | |
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs | - Markus Sabadello will move Phil hackmd comments to the Github repo as issues or discussions
- Daniel Hardman will donate his dh1128 repo if ToIP will allow.... all commits are signed
- Lance Byrd will provide an outline of how to use a TEL to verify the signature document
- Consider pros/cons and strategy for where reference implementations live
- Lance Byrd will start an ACDC PR to the spec that describes signing
|