Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 9
Next »
Meeting Link / Recording
- Video will be here
- transcript will be here
Attendees
This is a future meeting
Agenda Items and Notes (including all relevant links)
| 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:
Current work - Spec repo to be donated to ToIP if WG/TF is approved
- Previous reference impl was started here
|
| 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 | News or events of interest to members: - This is a provisional WG/TF and we hope to be officially under ToIP in September 2023
- IIW October 2023
- Do we want to define milestones, like IIW, for the spec and reference impl?
- DIF identifiers discovery
|
| 5 mins | Reports | Open |
|
| 25 mins | Discussion | Open | - https://github.com/dhh1128/did-method-webs/issues
- Activity this past week
- Stephen Curran reviewed the newly added did doc section information
- alsoKnownAs vs equivalentId
- whois
- weighted threshold multi-sig
- SSL/TLS common name
- https://github.com/dhh1128/did-method-webs/pulls
- Activity this past week
- Signed Files
- Whois
- VCs + JWS vs. Service Endpoint
- 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
 - 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?
|
| 5 mins | Any other business | Open | |
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs |
|