DID WG Telco — Minutes

Date: 2021-04-13

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

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