DID WG Telco — Minutes
Date: 2021-04-13
See also the Agenda and the IRC Log
Attendees
Present: Daniel Burnett, Shigeya Suzuki, Ivan Herman, Amy Guy, Justin Richer, Dmitri Zagidulin, Ted Thibodeau Jr., Charles Lehner, Dave Longley, Manu Sporny, Brent Zundel, Adrian Gropper, Juan Caballero, Jonathan Holt, Chris Winczewski, Drummond Reed, Joe Andrieu, Orie Steele, Markus Sabadello
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Juan Caballero, Brent Zundel
Content:
- 1. re-introductions
- 2. special topic call
- 3. IETF subject identifiers
- 4. status of at-risk items
- 5. JSON-LD Contexts in DID Documents
- 6. JSON-LD Contexts in the Registry
Brent Zundel: agenda review: LD Contexts in DID Docs & Registry issues, then Issue Review
Justin Richer: subject identifier thread on CCG mailing list
Brent Zundel: 5min, added to agenda
1. re-introductions
Juan Caballero: currently in california, here representing Spruce
2. special topic call
Brent Zundel: today’s topic call, 6pm est, did-test-suite
3. IETF subject identifiers
Charles Lehner: https://www.iana.org/assignments/uri-schemes/prov/did
Justin Richer: context on secevent thread
… big questions are one format or two and names
… account identifier has type URI; DID could have URI as type, DID could have URL as type, or there could be two formats
… URI field could be defined as a URI but named “ did” or named “uri”
Drummond Reed: +1 to including DIDs!
Manu Sporny: +1 to DID URL
Dave Longley: +1 to DID URL as the value
Brent Zundel: +1 to DID URL
Ivan Herman: +1 DID URL
Charles Lehner: i am wondering if it is consistent with the uri registration
… or should registration be updated to allow DID URL
Justin Richer: additional context on purpose/goal: identity assurance and auditing across systems
… also useful to GNAP
Justin Richer: I’ll change the field name to “uri” and send the text off to the editor – thanks everyone
Justin Richer: PR for Subject Identifiers changeset: https://github.com/richanna/secevent/pull/2
Manu Sporny: also, thank you to Justin for chasing that down! :)
4. status of at-risk items
Brent Zundel: end of april deadline for did core tests to be written and 15 of may for implementation reports
… to timeline next CR
Manu Sporny: screensharing
… spec as published
4.1. section 3.1 feature at risk warning
Brent Zundel: https://www.w3.org/TR/did-core/#did-syntax
Drummond Reed: the reason this was decided was that well-known method specific value could be used for discovery of did doc
… so we gave up on any justification for empty value
4.2. section 5.1.3 alsoKnownAs
Brent Zundel: https://www.w3.org/TR/did-core/#also-known-as
Manu Sporny: so we will drop that feature if nothing happens
Dmitri Zagidulin: uh ohs. did:web definitely intends to implement alsoKnownAs
Manu Sporny: 5.1.3 another feature at risk– here we need two implementations to keep the feature
Adrian Gropper: i have not been following alsoKnownAs closely, but
… is it useable for linking two dids? where inn the spec do we recommend a method for provably correlating two dids?
Manu Sporny: there are multiple spots where we talk about
Drummond Reed: Indy definitely uses it, so I will reach out to that dev team and see who can help write the impl. stuff and submit to test suite
4.3. section 5.2.1 feature at risk (publicKeyMultibase)
Brent Zundel: at risk feature in this section: https://www.w3.org/TR/did-core/#verification-material
Manu Sporny: publicKeyBase58 & pKMultibase can be allowed in extension but not in spec, we have options open
4.4. section 6.3.1 media type did+ld+json
Manu Sporny: 6.3.1 another feature at risk - media type registry
Brent Zundel: did+ld+json at risk statement here: https://www.w3.org/TR/did-core/#production-0
Ivan Herman: we should’ve done it earlier, now we’re stuck waiting on IETF
… if CR get republished, that would be the deadline to get a draft in to IETF
Orie Steele: can we halt wg activity until the mimetypes are registered properly?
Ivan Herman: per process we should’ve done it at CR time instead of just a comment; if we republish, we should definitely submit official proposal to IETF
Manu Sporny: editors will try to pose the question directly to IETF to speed up the process a little
4.5. section 6.4 CBOR serialization
Brent Zundel: at risk statement for CBOR here: https://www.w3.org/TR/did-core/#cbor
Manu Sporny: Orie has been working on it
… but is not finding 2 implementations of vanilla CBOR
Orie Steele: This description does not map to what people are actually implementing
… this normative text is not about DAG-CBOR or CBOR-LD, where the real action is
… we kept this open in case vanilla CBOR implementations were to arise, but we are not seeing support that would justify leaving it in the spec as is
… we should make the best-supported representations an integral part of the spec and IMHO remove this
Jonathan Holt: i disagree; i am back inn the groove of this group
Justin Richer: +1 to jonathan_holt ‘s point
Jonathan Holt: and have submitted 12000 lines of code, including working with CDDL NODE libraries to make a less JSON-beholden test apparatus
… protocol labs has joined W3C and they will be helping to find/write testable implementations
Jonathan Holt: hexadec repr of the CBOR and I’m currently working on the “test CBOR” test in the test-suite
Orie Steele: for which we need PRs
Ivan Herman: to be precise, at-risk status and test suite are orthogonal; what determines at-risk status is 2 independent and testable implementations by our deadline
… and CDDL is itself also orthogonal (although i personally support the CDDL work), the test-suite, and the support of this section of the spec
Daniel Burnett: And will we have that second implementation by mid-May …
Manu Sporny: to recap, we need two implementations by mid-may, but we have a big agenda…
… and I want to ask if anyone on this call is planning to submit a vanilla CBOR implementation besides jonathan_holt
… outreach would help
Jonathan Holt: 3Box may be interested, although not a w3c member
Manu Sporny: implementers need not be members!
Drummond Reed: +1 to implementations coming from anywhere
4.6. section 7 - dereferencing resolution section
Brent Zundel: at risk statement on resolution: https://www.w3.org/TR/did-core/#resolution
Manu Sporny: 7.1.3 - various at-risks in the resolution section
Brent Zundel: metadata at risk statements: https://www.w3.org/TR/did-core/#did-document-metadata
Manu Sporny: can we get the people on the call working on resolvers to list the sections they plan to support
Orie Steele: we are
Charles Lehner: +1 spruce
Orie Steele: transmute will submit
Charles Lehner: spruce as well
Drummond Reed: daniel buchner is not here
… but canonical is central there, i believe
… at sidetree i mean
Manu Sporny: nextUdpate nextVersionId
… may not be represented
Markus Sabadello: i’ve been working on how to test these fields, but they are often hard to write without deep knowledge of those methods
… i will attend the topic call today to discuss this
Manu Sporny: please attend the topic call if you have input/insight into these features
Markus Sabadello: Some statements in the DID Resolution sections I’ve had some questions about when writing tests: https://github.com/w3c/did-test-suite/issues/53
Orie Steele: can we merge did test suite PRs?
5. JSON-LD Contexts in DID Documents
Manu Sporny: LD context and suites
… (screensharing /test-suite/did-key-2020-db.json)
… the suites have largely been taken out of context
… leaving base context and the more or less explicit requirement that implementers add suites and curves in their contexts
… mix and match, no options taken off the table, just setting a different course for design of dependencies
Orie Steele: here is an example of a did method specific context: https://ns.did.ai/transmute/
Manu Sporny: security contexts could be bundled or composed
Dave Longley: consuming software that doesn’t care about DID methods but does care about crypto suites will prefer the individual crypto suites listed
Markus Sabadello: i want to mention that the DIF ID WG discussed this a bit
… that recording is public, for anyone curious
… there was talk of major breakage and versioning issues
Markus Sabadello: that said, i fully agree with this change, and this group never promised a static context and I feel this amount of breakage is within reason
Orie Steele: please don’t use resolvers to “fix” did documents… its like swallowing an error that should be thrown.
Manu Sporny: is anyone concerned about this?
… we need to put the word out that the core context HAS changed and every implementer should check if this affects their work
Markus Sabadello: Agree, Orie, except maybe for a transitional period, or with a warning
Manu Sporny: also, we should put the word out about this change in design strategy and guidance
6. JSON-LD Contexts in the Registry
Markus Sabadello: DIF call where this was discussed yesterday: https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md#meeting—12-apr-2021—1400-et-recording
Orie Steele: we have had some input about the registry
… one of the PRs suggested removing the explicit CDDL requirement
… making it OPTIONAL (i personally still recommend anyone interest in precision use CDDL to specify!)
… but it can create an addition burden on both submitters and reviewers
… secondly, another PR proposed removing CDDL registry altogether
Ivan Herman: i would like to reiterate that JSON-LD is NOT a schema language, we should be very explicit
… a context is “just” a mapping from terms to URL-s…
Manu Sporny: i want to support CDDL requirement being removed and thinning the registry; removing LD contexts is a bit more tricky
… i think we should collect implementers’ contexts and work with them a little
… i.e., submitters could optionally submit a pointer to a context, that we can then automatically process
… so that when we have something like publicKeyHex, we could (automatically) point to which submitted contexts use it
… as a non-normative utility/reference
Amy Guy: if we didn’t require jsonld contexts we don’t get any interop between representations with extensions, do we?
Markus Sabadello: when we set up the registry, that was one of our requirements: providing an LD context
… to enable lossless conversion between reps
… and i still think that it is useful
… in ways many people don’t realize
… for example, we recently had a case where verificationMethods were being defined differently and non-interoperably between otherwise conformant methods
… so having their contexts on hand was very useful in understanding the problem
… and each method somehow linked to its corresponding context is useful for detecting and mitigating
Dave Longley: i agree with markus
Drummond Reed: +1 to keeping the requirement for JSON-LD contexts
Dave Longley: if we don’t link the context in the registry, people will end up having to look for them in the spec for all these reasons
Orie Steele: i understand this, unfortunately i think this is a problem of the ADM
Markus Sabadello: WG resolution where we agreed on this requirement: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-01-30-did#baseline
Orie Steele: we are having our cake and eating it, too, if we allow people to not support LD (i.e. throw “rep not supported” error, which is conformant)
… and still ask them to submit an LD context?
… i don’t know that cluttering the registry with bad examples of LD helps us produce interoperability
… bad LD contexts going into the registry is more harmful than having no registry
… and registry does not currently have the resources to adequately analyze and improve LD at time of submission
Ivan Herman: perhaps a middle ground is possible here
… what if registering a term requires registering the URL of the term, instead of a URL that points to a context?
Dave Longley: the point of the registry was for properties that are meant to be expressible in the various representations – which means saying how your registered terms can be expressed (and +1 to what ivan is saying, you need a globally unambiguous ID for your term)
Dave Longley: you may also want to provide a URL for the type of expected value
Drummond Reed: +1
Orie Steele: we clearly don’t need JSON-LD unambiguous terms or we would not have added a representation like did+json that specifically does not use that.
Drummond Reed: +1 to @dlongley’s suggestion of the value URI
Drummond Reed: URI representing value, not type
… pace dlongley
Drummond Reed: To be clear: both URIs - one for the property and one for the value