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
Version 1
Next »
Meeting Link / Recording
- Currently processing will post it ASAP
Attendees
Markus Sabadello
Stephen Curran
Daniel Hardman
Alex Andrei
Lance Byrd
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:
|
| 5 mins | Review of action items from previous meeting | Chairs | - This was our first meeting
|
| 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 a month
|
| 5 mins | Reports | Open | Artifacts of previous work - temporary spec
- Phils hackmd has been included in the spec and no longer should be used. Comments will be moved to issues.
- Reference implementation
|
| 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
- Markus diagram to pompt discussion for the ecosystem and reference impl
 - resolver is the did:webs verification client
- the service and resolver will BOTH use keri-diddoc.py
- 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
- 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 | - 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
|