| 25 mins | Discussion | Open | - Shall we prioritize the work based on MvP, milestones, etc?
- 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?
|