Special Topic DID call (registries) — Minutes

Date: 2020-03-05

Attendees

Present: Daniel Burnett, Chris Winczewski, Orie Steele, Eugeniu Rusu, Jonathan Holt, Amy Guy, Charles Cunningham, Michael Jones, Dave Longley, Yancy Ribbens, Manu Sporny, Markus Sabadello, Joe Andrieu

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Amy Guy

Content:

Daniel Burnett: https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0000.html

Orie Steele: See proposal here: https://github.com/w3c/did-core-registry/issues/3

Dave Longley: see also: https://github.com/w3c/did-core-registry/issues/13

Dave Longley: for a task list

Orie Steele: And regarding normative definitions: https://github.com/w3c/did-core-registry/issues/9

Daniel Burnett: this is a discussion, we’re not taking decisions
… Decisions will happen as normal with github issues and prs. This group could come to what they believe everyone is happy with and then create PRs from that

Orie Steele: high level, what we’re trying to do is get the registry into shape where we can start to add properties at a more rapid pace. We want to make sure we agree to the structure and tech and foundation while it’s small, and then as we add properties [..] definitions as we go
… we don’t want to update thousands of properties all at once because we decided the structure of the registry should cahnge drastically. It should change incrementally
… there are a couple of key themes to consider
… one is the mechanism for ensuring the registry dfns are valid internally, machine readable as much as we can
… there is the concept of where’s the human readable documentations associated with the registry entries. That gets into, the registry is pointing to other sources, including the DID core spec, and we want to be on the same page about how that referencing for human readable definitions is happening
… a final point would be this registry has the potential to be valuable in terms of demonstrating did method interop and compliance and testing
… I’d love to be able to take advantage of that
… historically we’ve had jsonld machine readable definitions for the concept of a registry
… the major change now is to add json schema to support the json only representation with a level of specificity that is excellent, and benefits the jsonld representations as well as the json only ones, and potentially also the cbor ones

Manu Sporny: +1 to everything Orie said
… I have tried to take a number of the statement Orie has said and I’ve tried to boil them down into very specific things that the group needs to agree to
… We have to come to consensus on some core principles
… and a checklist of if we agree to the core principles, these are the things we need to do to enact them and make this registry the stable thing that all implementers can depend on

Manu Sporny: https://github.com/w3c/did-core-registry/issues/13

Manu Sporny: I would like to go through this ^
… 16 items to discuss and/or agree or debate
… if we get through all of those items, I believe we will get to a good stable process around the management of the registry
… that list contains a number of things Orie said as well as other detailed things
… Clarifying questions?
… After that we’ll start going through that list, it touches on the items Orie touched on, and if we need to do a deep dive on some of them we can

Michael Jones: I’m going to use https://www.iana.org/assignments/jose/jose.xhtml as an example when I speak

Orie Steele: I think your issue is a better place to start

Manu Sporny: yes, this is a set of registries.

Michael Jones: one foundational thing is we need to start using terminology the same way
… referring to ‘the registry’ is misleading because per example the example I just put in the chat, the jose registries document
… take 5 seconds to see that
… you will see in this registries doc run by iana that there are 9 different registries that are related to each other, all in the same registry document
… I’m certain that’s going to be the case with us, we’ll be registering more than one kind of thing
… top level did document params, did methods, we may have registries for algorithms, these are different registries, it’s not ‘the registry’
… we should start using that terminology
… that will align us with the way the rest of the world uses the term registry, as a repository of things of the same type

Manu Sporny: +1 to that, I think.. any objections to what mike said? I think consensus in the group is yes, this will contain multiple types of things that are similar in nature

Orie Steele: yes, thats the intention

Daniel Burnett: I agree with mike, I want to point out something a little strange about our conversation
… the registry document you’re looking at that mike provided shows a number of different iana registries. The way iana registries work is as you see it here, you have a registry and links to other pieces of information
… w3c is still working out exactly how they want their registries to work, but there’s a possibility that we’ll have a document that contains the content, not just references
… I agree with you mike, we are going to have multiple registries because there will be different types of information
… how they’re represented may be confusing in the end
… there may be one document that contains multiple registries that themselves contain entries
… but I agree with you we should talk about them as registries as long as we understand that how they’re specifically represented is going to be worked out

Michael Jones: that’s fine, I just want us to use consistent terminology

Manu Sporny: with that, if there are no objections to what mike and dan just said, let’s get into the list
… I’m going to read through the list
… there are going to be multiple people objecting to multiple items on this list
… I want to explain why each item is there and then we can go back through and determine any objections
… The first 3 are checked, we had consensus at the f2f to do at least these things
… the items unchecked are all of the questions that came up after the f2f about how we’re going to operate the registries
… it says DID core registry, but read that as DID core registries
… read registry as registries
… There are a set of things we need to agree to, and then a set of things we need to do
… first list is agree to, second is to do
… First item is something I believe we got consensus on at the f2f
… Any addition to the DID Core Registry MUST specify a human readable description of the property and point to the appropriate specification for that property.
… the latter part might be controversial
… second: Any addition to the DID Core Registry MUST specify a machine readable JSON-LD Context for the property.
… third: Any addition to the DID Core Registry MUST link the machine-readable property in the JSON-LD Context to the human readable description.
… this is a best practice and people assume it, but I thought it’d be best if we state it explicitly
… next: Any addition to the DID Core Registry MUST specify a non-normative JSON Schema for the property.
… this is something that orie raised at the beginning of the call, it allows some level machine verification of the json
… lets us automate some of the checking instead of relying on humans
… next: Any addition to the DID Core Registry MUST be placed in a sub-namespace if it isn’t in the DID Core Registry. For example: https://www.w3.org/ns/did/btcr/ and https://www.w3.org/ns/did/btcr/(v1|v2|v3).
… this has to do with did methods and how they might expand upon the registry
… we could do it in a variety of ways
… kitchen sink approach like schema.org, has a number of downsides
… we want to enable did methods to operate independently but still have a place to register all of those items
… next item is Properties in the DID Core Registry MUST NOT be removed, only deprecated.
… if we do anything other than this it creates potential interop and implementer concerns. We need to discuss that. Hasn’t been brought up before
… next: JSON-LD Contexts MUST NOT be date stamped. The Verifiable Credentials will need to be fixed.
… goes back to a decision made previously in the did wg, trying to apply something consistent to all of these
… definitely not what the VC spec did. We may want to revisit that decision
… we need to figure out what we’re doing here because the number of contexts we have is going to be much larger
… next: JSON-LD Contexts MUST use scoped terms and the @protected feature to eliminate the possibility of term conflicts.
… this is to ensure that people don’t step on each others toes and create some machine level enforcement of that
… works in concert with the json schema stuff
… the last one is: The DID Method registry will be included in this registry.
… the DID method registry is maintained by the CCG
… If we do this we can have one document that lists all DID related things, so there’s one place for people to go to
… The subsequent list depends on us agreeing on a subset of these items

Daniel Burnett: meta comment. A number of these items are there because of the JSON-LD representation. Some are there because of the JSON-only representation
… I dislike seeing them all piled together in a list because when someone later wants to add another representation, or when we need something like this for cbor as well, it’s easy for people to forget or misunderstand that the reason we need those is in order to support that representation
… keep that in mind, bring it up if relevant, I don’t think it changes our conversation now, but in the future grouping them by the kind of representation might help

Michael Jones: one of them uses terminology that’s not understood by me
… What do you mean by MUST be place in a sub namespace? Must be at a URL?

Manu Sporny: Yes. There’s an example there
… https://www.w3.org/ns/did/btcr/ and https://www.w3.org/ns/did/btcr/(v1|v2|v3).
… BTCR may be doing things other DID methods don’t do so it gets its own context file
… a sub namespace via a URL that contains the BTCR only properties as well

Michael Jones: the examples make it look like everything has to be at w3c. It might be the case that ISO or Microsoft have its own namespace
… These are just URLs that have to be distinct
… asking people to put these at w3c namespaces is onerous

Jonathan Holt: I think a URI rather than a URL..

Manu Sporny: URIs are not always dereferencable and it makes it more difficult to publish a human readable version if it’s a URI that can’t be dereferenced, that’s the only hesitation I have jonathan_holt, one of the thing we agreed is that we would have human readable documentation

Orie Steele: I prefer URL.

Manu Sporny: if it’s not easy to paste that into a browser and find the docs it potentially goes against something the group agreed to
… In response to Mike, at a high level I agree, but it seems to go counter to some of the things that the JSON only folks wanted which was a registry that’s more centralized than decentralised
… what you said mike is completely compatible with the jsonld view of the world and is what the jsonld folks were arguing for, so I’m confused by you saying that. I think we should do it, I’m just surprised to hear you say that

Michael Jones: if you look at the jose registry, it points both to stuff that is in rfcs and stuff that is in other places
… that’s normal. Any healthy registry is going to have entries made by other organizations if the technology is vibrant
… so those other orgs and individuals will have different namespaces and should be empower to use them and not increase the weight of the process
… the only thing that’s centralized is presentation
… references to the definitions

Orie Steele: I agree that the did-core-registries will link to external sources, including IETF, W3C, etc….

Markus Sabadello: my question was whether the subnames would be inherently linked to the did method registries, would they be specific to certain methods. We have method specific DID params, if there was a registry for that, how method specific things in the registry would relate to this namespacing

Manu Sporny: those are all very good questions
… since the queue is exhausted if we want to go through each one of these items one by one now?
… any objections?

Daniel Burnett: to find out quickly which ones do not have objections, so we can get them checked out? then go back to the ones with objections?

Dave Longley: instead of “objections” just say you want discussion

Manu Sporny: okay, going to run down the list, if you have an objection please say so, and if there is we will not check it and skip to the next one. If there are no objections I’ll check it and we’ll move on
… if you object please be ready to say how you’d change it
… First one; human readable description of property and point to appropriate spec

Michael Jones: i object to the wrong terminology. Needs to be changed to plural

Manu Sporny: going to go in and modify to say registries really quickly
… and I expect we need an item to rename the title of the repo to say registries

Daniel Burnett: I have future comments on the term “DID Core Registries”, but I’m fine with it for now as an improvement over “DID Core Registry”

Manu Sporny: First item: title should be changed to DID Core Registries. Any objections?
… Nope, checked the box
… Next, human readable description and points to spec. Any objections?

Jonathan Holt: define point?

Manu Sporny: a link, a URL

Jonathan Holt: I object
… a URI would be fine
… you’re specifying a protocol, there are plenty of other identifiers that satisfy the same functionality

Joe Andrieu: I want to push back agains that, the distinction here is this has to be dereferencable so you can get to the spec. Simply having an identifier doesn’t do that. If there’s something other than a URL that is guaranteed to be resolvable?

Jonathan Holt: defining resolvable is the next thing.. not just points, point and resolve
… you can do that with oid-s

Manu Sporny: I updated it to break this out and make the second item simpler

Michael Jones: the link that programmers use to go read the spec
… if you can’t follow the link the programmer doens’t know how to implement the registry entry
… you could put an oid there but it means you’d have to doa search on the web for whatever purports to define the oid
… every oid is defined in a document. The link in the oid case would be a link to the specification that defines the oid. The oid would probably be part of the registry, the value, but you still need a link to the defining document so people can implement it
… this is for programmers

Orie Steele: Lets not bring other protocols into world wide web consortium registry…. it needs to be something that works in a browser

Orie Steele: Feel free to use a gateway: https://example-gateway.com/ipfs/QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy

Daniel Burnett: can we stop discussing right away? I’m sure we’ll come back to it, but would it be possible to go through the list and out which ones have objections instead of trying to resolve them each individually?

Manu Sporny: +1. In this case i’ve split it into two where we agree one and not the other
… the second item is now, must specify human readable. Any objection?
… that’s checked. Skipping the URL one.
… Next is any addition to the registries must specify a machine readable jsonld context for the properties. we had consensus at the f2f. Any objections?

Jonathan Holt: I have reservations, not objections

Manu Sporny: that’s remaining checked
… Any addition must link the machine readable context to the human readable description. This is best practice, and agreed at f2f
… objections?
… hearing none, staying checked
… Any addition must specify a non-normative json schema for the properties
… objections?

Michael Jones: why non normative?

Orie Steele: because the the registry is a note not a specification.

Manu Sporny: if it were then the json schema owuld be normative, and then it would raise questions about whether it should be included in the spec, and raises questions about the normative nature in the json schema

Michael Jones: I’m okay with the language provided you put in a parenthetical saying it’s the spec that is normative

Manu Sporny: any objections to the parenthetical?
… the specific text is “(the specification is normative)”

Michael Jones: sure

Manu Sporny: updated: Any addition to the DID Core Registries MUST specify a non-normative JSON Schema (the specification is normative) for the property.
… checking
… Any addition must be placed in a sub namespace if it isn’t in the DID core registry

Orie Steele: this applies to ethereum and bitcoin

Orie Steele: and also sidetree

Michael Jones: the last bit is confusing and not actionable

Manu Sporny: next - properties must not be removed, only deprecated. Objections?
… checking that.
… JSON-LD contexts must not be dates tamped

Michael Jones: I object to the second sentence because it’s out of scope

Manu Sporny: striking that, any objections to striking that?
… any objections to the first part?
… checking that
… JSON-LD contexts must use scope terms and the @protected feature. Objections?

Markus Sabadello: This would preclude the use of JSON-LD 1.0

Michael Jones: I don’t understand this well enough to evaluate it

Jonathan Holt: I thought JSON-LD 1.1 was still draft? so it’s hard. It’s heavy handed on JSON-LD, I have reservations

Michael Jones: is this all to prevent name conflicts at the json level?

Orie Steele: JSON Schema is used to protect “Pure JSON”

Dave Longley: i think the use of scoped terms should be a SHOULD not a MUST

Manu Sporny: at the JSON-LD level. The JSON level will probably be enforced by json schema
… this is a mechanism for the json-ld only people to ensure that won’t happen

Michael Jones: then we can move on, but the way you avoid name conflicts in json is by registering the name, so it’s the registry that eliminates the conflicts

Manu Sporny: this is for machine processing, not human processing
… the goal is to make this stuff machine enforceable and this assures that it’s machine enforceable in json-ld
… okay, skipping this one, needs more discussion
… last one, the DID Method Registry will be included
… right now the CCG has it as a separate document. We should include it in the DID Core Registries

Dave Longley: “in the DID core registries”

Manu Sporny: objections?

Michael Jones: into this “set of registries”

Manu Sporny: “The DID Method registry will be included into this set of registries.” objections?
… checking that
… Let’s try to address the easiest things

Markus Sabadello: can we propose to add things to the list?
… Similar to the last item, a DID parameter registry will be included or added (this is independent of the matrix params, could be query params)

Manu Sporny: to be clear, the DID parameters, one way of expressing them is through matrix parameters?

Markus Sabadello: that’s not decided, ongoing discussion. Even if they’re removed there will still be something called DID parameters, independently of how the syntax is implemented. There is a list of them in the spec right now, perhaps that should be in the registry

Manu Sporny: added to the list. objections?
… Now the remaining 3
… Easiest, the JSON-LD restriction, must use scoped terms and the @protected feature

Daniel Burnett: All this is good for now. Eventually we will need to name and talk individually about the various registries to keep it clear which statements and actions apply to which registry

Dave Longley: My suggestion is to make the use of scoped terms a SHOULD to allow flexibility for cases where it’s just not gonna work, but keep the MUST on @protected

Manu Sporny: I’ve updated it

Dave Longley: I agree to that

Manu Sporny: any objections or concerns?

Jonathan Holt: I think the concern is how to enforce across either json-ld and the registries to make sure they’re in sync

Orie Steele: this registry of registries with these contexts defined here allows us to programmatically ensure that property so long as this item is actually enforced
… if we want to be able to ensure what we want, we need to agree to this for JSON-LD

Jonathan Holt: I think the onus is on the JSON-LD ot update those protected terms based on the registry? My concern is about this mutable link as being the source of truth
… to satisfy my reservation, a mitm attack or ssl proxy forging, i could redirect you to a different URL, change the namespaces and convince you
… the way we handled it in hl7 is we had a url that went to the schema but we also included a system with the oid, example:

{ "url" : "http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type",
 "identifier" : [
 {
 "system" : "urn:ietf:rfc:3986",
 "value" : "urn:oid:2.16.840.1.113883.3.88.12.80.32"
 }

Jonathan Holt: the url would be jsonld @context parsing that includes a url link that has the protected fields. The system in this case is rfcs, very specific to the attributes. Could be a string that defined the attributes

Orie Steele: I think that sub resource integrity checking or other mechanisms for ensuring the uri is coupled to the machine readable definitions for all of the syntaxes is a secondary concern to the specific technologies we use for one
… for cbor we’re going to have some differences for how we’ll ensure integrity for cbor
… I agree with what jonathan_holt is saying, we need to tackle that subsequent to defining that there’s a uri and a document that is resolvable

Dave Longley: my understanding of these registries is the literal content of a json-ld context or jsons chema would go into these registries so it could be hardcoded in these applications?

Orie Steele: we are planning on doing that

Manu Sporny: we are planning on doing that

Dave Longley: so we don’t have a MiTM problem.

Orie Steele: +1 to integrity mgmt being out of scope’

Michael Jones: discussions of how to ensure integrity of the references should be out of scope right now. we could host signed versions or all sorts of stuff, let’s not overcomplicate

Manu Sporny: just to close this set of thoughts out, we did have to deal with this in the VC spec. We specified a resource integrity hash and provided a static version of the document and said it wouldn’t change
… I expect we’ll do something similar here, but we need time to figure it out
… We need to discuss that in parallel
… Now we’ve had that discussion, does anyone object to this text?

Jonathan Holt: the onus is on JSON-LD. That’s one way of solving the problem if you’re using jsonld context

Manu Sporny: that is true
… we’re recommending that as a minimum thing

Dave Longley: the onus is on whoever is submitting to the registry to make sure they have a valid json ld context that applies to the rules, and whoever is managing the registry to make sure that’s true
… strange to say the onus is on the technology
… onus is on maintainer to make sure the rules are enforced

Manu Sporny: any further concerns or objections?

Jonathan Holt: more just brainstorming how to keep things in sync. If you want to use jsonld context and protected fields that’s fine, but if you want to use json only and point to a URI to say here’s how you do that, ..

Manu Sporny: we’re talking specifically about JSON-LD not JSON

Orie Steele: we need to get through the list.

Orie Steele: please stop derailing us.

Jonathan Holt: I’m concerned because it’s about JSON-LD, I want to have a more broader discussion about how to solve it

Manu Sporny: we need to have that, but it’s not necessarily this discussion

Jonathan Holt: should have protected fields, great way to solve that

Manu Sporny: Remaining - link via URL to specification for that property
… other one is sub namespace item
… not sure which is easier
… Let’s take the link

Dave Longley: in case there’s a misunderstanding here … if you want to use the registries you have to provide for every representation (which includes JSON-LD) so we can have lossless transformation

Michael Jones: it might make this less ambiguous if we added text of the kind “a URL to the defining specification so that programmers can find it to implement it”

Orie Steele: that language I find it useful
… A note that one of the kinds of links that we’ll be adding are links to normative language for things in the DID COre specification, because the registries is a Note
… hypothetical external links could be to the iana jose registry, and links to other w3c registries that might exist in the future

Manu Sporny: updating to mike’s text
… “Any addition to the DID Core Registries MUST link, via a URL, to the defining specification so that implementers can implement the property.”

Jonathan Holt: here’s an example pointing to a URN (which is a URI) which goes to the spec that describes all the values: urn:ietf:rfc:3986
… that solves our problem just allowing URIs

Michael Jones: that’s not resolvable

Orie Steele: I object to URIs… it should be a link that works in a browser.

Jonathan Holt: most people would know where you go to download it

Dave Longley: put a URI in AND a URL so you say where it is… if you want a URI in there, you must ALSO put a URL.

Michael Jones: there’s a url for that rfc, i don’t know why you want that URI

Jonathan Holt: you could use a URL too

Manu Sporny: we’re out of time, thank you for the discussion we got through a lot more than I expected
… We have two items to clear off the list
… During our next call we’ll keep going through this
… Try to think of some modifications that you could make that would make you happy

Dave Longley: “most people know where to look” <– then the “most person” submitting to the registries could put the URL in there too :)

Orie Steele: Thanks!

Manu Sporny: Thanks everyone for the call