| 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 | - Consider pros/cons and strategy for where reference implementations live
- 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: - 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?
- Arrive with a coherent draft, already registered in DID registry
- Also arrive with reference impl in DIF Universal Resolver
- did:plc discussion
|
| 5 mins | Reports | Open | - Upcoming milestones
- IIW Fall 2023
- There are several potential opportunities, Daniel Hardman will report soon.
- DIF identifiers discovery
- Great conversations about JWS signatures and security characteristics
|
| 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?
- 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
- https://github.com/dhh1128/did-method-webs/pull/26
- 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?
- Note: discovery information (less security needed, Best-available-data )... a level of replay attack information, but can be DDOS attacked.
 Image Added
- 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.
- 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?
- 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
|
| 5 mins | Any other business | Open | |
| 5 mins | - Review decisions/action items
- Planning for next meeting
| Chairs | |