| 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: - ToIP Approval for Open Web Foundation IPR license
- 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 and Dimiti's did:web 2.0 (next gen) proposals discussion.
|
| 5 mins | Reports | Open | - Upcoming milestones
- IIW Fall 2023
- There are several potential opportunities, Daniel Hardman will report soon.
- DIF identifiers discovery
- In next Monday's DIF ID WG meeting, we will talk about "lifecycle of did:web identifiers" which also seems related to this topic
- Great conversations about JWS signatures and security characteristics
|
| 25 mins | Discussion | Open | - Reference implementation repository considerations
- Universal Resolver impl at DIF?
- Must have a dual membership at ToIP and DIF, is this only for maintainers? What are the rules for contributors? There is some legacy concerns from previous initiatives. There were legal issues related to participants from larger companies.
- Open Wallet Foundation for wallet related repos?
- WebOfTrust as a neutral location
- Hyperledger?
- More code related repos.
- You don't have to be a Linux Foundation member
- Must have a Github account and sign with DCO
- It would be easier to live as a Hyperledger Lab, a little more work under Aries, and significant work as it's own project under HL.
- Stephen Curran can get the ball rolling for HL Labs.
- Trust over IP?
- Does this have the same issues as DIF? No, a different policy
- 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.
- 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?
- Markus Sabadello will lead us in discussing did:webs + did:keri.
- Significant overlap, we discussed advantages and disadvantages. Samuel Smith feels that listing the advantages/disadvantages is useful and is open to separate specs.
- DID Document generation would be very similar, with differences specified.
- The lifecycles would differ:
- did:keri lifecycle would follow the AID.
- did:webs is downloaded.
- Stephen Curran recommends that we focus on did:webs and that they be separate independent specs.
- What is the relative set of KERI events that are used to create/update. Name, purpose, and input values. Then an explanation of how it works in the DID document and underlying in KERI.
- Samuel Smith noted that did:webs should have a mechanism to securely transfer to a domain name. did:keri doesn't have this corner case. But we should consider to maintain the persistence of a did:webs if you lose control of a domain. Also in the past Phil Feairheller has mentioned that we should support a mechanism to avoid allowing just anyone to create a did:webs for an AID they don't control.
- Alex Andrei noted this can be part of the events we need to define for the “update” functions
- Phil Feairheller thinks this is a great start for did:keri. He agrees this doesn't belong in did:webs. He sees no problem copying sections between them.
- 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 | - Lance Byrd will collect the events/details in relation to switching domains. This should be a one-to-many binding, not just a single domain. Guide readers to focus on the specific domain.
|
