Meeting Link / Recording
- did:webs provisional TF
Friday, September 8 · 10:00 – 11:00am
Time zone: America/New_York
Google Meet joining info
Video call link: https://meet.google.com/rpd-gjgd-nah
Or dial: (US) +1 563-557-7710 PIN: 850 219 169#
More phone numbers: https://tel.meet/rpd-gjgd-nah?pin=7665699145995 - Recording will be posted after the meeting
- Transcript will be posted after the meeting
- Chats will be posted after the meeting
Attendees
Attendees
Markus Sabadello
Stephen Curran
Drummond Reed
John Jordan
Charles Lanahan
Nuttawut Kongsuwan
Lance Byrd
Wenjing Chu
Rodolfo Miranda
Samuel Smith 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 will be donated to ToIP if WG/TF is approved
- Previous reference impl was started here, See below for future Hyperledger Labs
|
| 5 mins | Review of action items from previous meeting | Chairs | - Stephen Curran is pursuing a Hyperledger Labs repo for the resolver reference implementation
- Markus Sabadello will make his did:webs and did:keri comparison available so that the sub-community interested in did:keri can collaborate.
- Lance Byrd will start an ACDC PR to the spec that describes signing
- Lance Byrd will provide an outline of how to use a TEL to verify the signature document
- Daniel Hardman will donate his dh1128 repo if ToIP will allow.... all commits are signed
|
| 5 mins | Announcements | TF Leads | News or events of interest to members: - ToIP has approved the Open Web Foundation (OWF) IPR license
- This is a provisional
|
WG/- TF and we hope to be officially under ToIP in a month, or so
- From the TSWG:
- ACTION: Drummond Reed to send an email to the TSWG mailing list notifying all TSWG members of a 7 day review period for the proposed DID WebS Method Task Force, followed by a 7-day email vote seeing if there are any objections.
- ACTION: did:webs Task Force leads to contact Michelle Janata to add their Friday meeting onto ToIP calendar once the Task Force is officially approved
- IIW October 2023
- We aim to be registered did method and have an implementation in the Universal resolver
- did:plc and Dimiti's did:web 2.0 (next gen) proposals discussion.
- did:webplus
|
| 5 mins | Reports | Open | - Upcoming milestones
- IIW Fall 2023
- There are several potential opportunities, Daniel Hardman will report soon.
- DIF identifiers discovery "lifecycle of did:web identifiers"
|
| 25 mins | Discussion | Open |
- Is a secure did:web spec adoptable, without additional features? Or do we require NEW features like whois, signed files.... if so, can we agree on what else is required?
Image Removed
The default should be secure?Verbose solution, Appraisable Security Level API: The spec swells in order to detail multiple 'levels' of security in order to accomodate both familiar and secure mechanisms.- Bare JWS provides file integrity, but not authenticity
- Best-available-data RUN is only acceptable for discovery information, file integrity and monotonically increasing (date)
- KEL anchors for integrity and authenticity
Hybrid solution: You can't publish the JWS without anchoring in a KEL first?Or perhaps, anything not secured by KERI is not did:webs, it is did:web?whois and JWS could be a PR to did:web and the ACDC anchored signature is did:webs- Bright line rule: For features that aren't secure, submit them to did:web?
- Note: discovery information (less security needed, Best-available-data )...
|
a level of information- , but can be DDOS attacked.
|
Daniel Hardman suggested last week that we explore the 'notion that did:web can borrow the view of did:webs" during our discussion about using JWS vs. ACDC.- Markus Sabadello diagramed the different resolver architectures, pros/cons, support for did:web, etc. https://github.com/peacekeeper/did-keri-resolver/
- Generate a did doc and oobi file so that you can publish them to any web server
- Then resolver verifies the did doc using the oobi file
- Who is the verifier? the resolver
- Does it need an oobi or does it need all of the events (KEL/TEL) like a Watcher does
- The verification is verifying that the did document is properly formed.
- Don't need a pool of watchers, But then availability attacks are potentially a problem.
- Do we rewrite the watcher to handle a file format that doesn't exist. Currently it is stored as a content addressable database, the database can restream the database in case of loss.
- Watchers stores KELs/TELs
- To store the KEL in github, you would need to re-verify it each time.
- The watcher could bootstrap from this file, but that is very expensive.
- Watcher code is designed to verify on the fly, making caching very important for scale.
- Verify only the latest events when a KEL is updated
- If there is a presentation, etc. you want to asynchronously update.
- Use Case. I get a univerisity did
- I verify the did doc when i get it.
- Can the resolver cache OOBIs? Yes
|
Bright line rule: Should the core of did:webs be the more familiar but less secure options, like JWS? Or should those be extensions to the did:webs spec? |
| 5 mins | Any other business | Open | |
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs | - Lance Byrd Create a PR for the spec that abstracts the verification information to CESR resources/mime type (not files) to support multiple reference implementations. The resolver can use local file(s), OOBIs, Watcher pools, DB/cache, etc for verification as long as it results in secure KEL/TEL verification.
|
