Storing normative properties? #9
Comments
|
Lets expand on and here:
technically in the current version of the did-core json-ld context, it is defined formally here: https://w3id.org/security#publicKey ... which redirects to https://web-payments.org/vocabs/security#publicKey So my question is... which of these definitions is the current normative one?.. I think its the w3id.org / web payments link... not the did core link which relies on w3id.org/security to define IMO, https://w3id.org/security#publicKey should be pointing here (https://w3c.github.io/did-core-registry/#publicKey), which in turn should contain a reference link to https://w3c.github.io/did-core/#dfn-publickey. In the did core context, Ed25519VerificationKeys are defined in exactly the same place as
In the case that https://w3id.org/security#Ed25519VerificationKey2018 would point to https://w3c.github.io/did-core-registry/#Ed25519VerificationKey2018... we might be able to point to other places where this term was used, but it would be defined in the core registry... I'm having trouble wrapping my head around how the registry does not contain the normative definitions for all terms relied on by did-core... just as w3id.org currently defines (or does not) all the terms used by did-core that are prefixed with I think what we want is the following structure: https://www.w3.org/ns/did/v0.11 -> https://www.w3.org/ns/security/v1 -> https://www.w3.org/ns/security/v2 -> https://www.w3.org/ns/security#publicKey-> ^ This last one should as you noted, include some clear respec UI which indicates that the normative defintion for https://w3c.github.io/did-core/#dfn-publickey Which will eventually be https://www.w3.org/ns/did#dfn-publickey right? So what will the url of the did core registry eventually be? https://www.w3.org/ns/did-core-registry#publicKey ? I think we need to map hypothetical w3.org urls through existing w3id.org urls to github repos first, and then decide how to label the definitions properly... The sooner we get the json-ld contexts out of did-core and into the registry the better IMO.... in the long run, i could see us merging the registry back into did-core, when people realize that normative definitions will now be split across 2 separate locations.... |
|
@msporny If i got the concept of a normative definition mixed up with a vocabulary defintion here, it would not be the first time :) |
|
@OR13, my apologies for a very short answer to your long note. It is not that I dismiss it at all, but I have my hands full of some other problems (mostly personal) the coming days. But there is one point that is important and determines everything else:
The answer is: per W3C rules, it is https://w3c.github.io/did-core/#dfn-publickey or, to be even more precise, https://www.w3.org/TR/did-core/#dfn-publickey. That is the only recommendation in the pack. The registry document is a Working Group Note, and the various vocabularies, by themselves, are embodiment of the standard which is the Core spec. Yes, you are right, the core document has to be thoroughly checked to ensure that the chain of references are all normative, and issue that I have already raised elsewhere. As for the core JSON-LD context: if we want that to be normative, too, we must include it in the core document itself. At this point, it is not... You are absolutely right that the interrelations of the various vocabularies, their governance, etc, require some further care (afaik there may be a separate call on that, I hope I can be on that call). (There is a rationale to all this: once published, the normative texts is, sort of, cast in concrete. There are separate procedures to change it, add something to it, etc, but it provides a 100% stable reference to everyone, its URL is guaranteed to be stable and, on a very practical level, the It is our decision whether, e.g., |
|
Thanks for this explanation :) ... very helpful! I think we can proceed as soon as I have a good way of noting the cases in the registry where the normative defintion exists in did core. I can take a stab at something like that in an upcoming PR. |
|
+1 not putting properties from did-core into the registry.
I would go so far as to say we don't even need to do that. Perhaps a sentence to remind people that the terms that you'll see in the core json-ld context and/or json schema are defined in the did-core spec, without having to list them - otherwise we have to keep the lists in sync. |
|
... we have to put the property into the registry, but we are not allowed to define it normatively there... this is the result of the compromise at the F2F... and the terms defined in JSON-LD and JSON Schema ARE NOT defined in the did core spec... at least right now... and if we are saying they all will be... why did we create a new repo for the registry? IMO, we need these things separated, the registry should be lightweight, and define all the terms, and the did core spec, can keep... being itself... defining some terms, not defining others, etc... everything needed for interop will need to be defined in the registry, but did core can choose to define stuff that is not needed or interop, or not define stuff that is needed for interop, as is the case today... at the end of this, when we have everything defined, we might consider merging the registry and the did core spec... What we can't do is define 1/2 the terms needed for interop in did core, and the other half in the registry... And we certainly can't define everything needed for interop in the registry if we are not allowed to add normative properties with a note about where they are defined... because things like |
|
My understanding was that the registry was just for extensions, ie. not things that are in the core spec. Everything in the core spec is needed for interop, and therefore normative. Extensions need to be defined in the registry in order to guarantee interop between implementations that want to use those extensions, but they are not part of the core, and not every implementation will use every extension. Perhaps I need to re-read the f2f minutes to understand better what was agreed. |
I think there might be some things missing from the core spec that need to be added.. but that aren't missing on purpose. I think there might also be some things that people want in the core spec that there isn't consensus on, and therefore will need to be extensions - and thus registered (defined in the registry). Some method-specific terms might fall into this category. The JSON-LD context is not normative itself, but a particular way of representing the normative properties from the core spec, which is why the registries repo is a good place to store it. |
|
yes, i agree. For example, not all did methods may want to use Everything that is defined in the context, needs to be defined in the registry or we won't get interop. Right now, my main goal is to either get properties removed from the did core context that don't have definitions, or get them defined at least in the did core registry. We have a lot of work to do with existing properties before we can even think about adding new ones IMO. |
I'm not 100% sure what the group consensus on properties that not all methods use is. Perhaps a clear decision on this hasn't been made yet (related: w3c/did-core#205)? It could be that "implement" just means "not drop on the floor in processing if you don't recognise it" in which case it means methods might not be able to authenticate a particular DID that uses
If it is decided that
I don't think that's true. Things can be in the context can have their normative definitions in the DID Core spec, and don't need to be in the registry. In fact, I think everything in the DID Core context should be in the core spec, not the registry, although I can see arguments for non-core-spec items being in the core context. (Aka important/common extensions that we didn't get consensus on to go in the normative spec, could go in the core context to help people, as the context is non-normative, but their definitions would be elsewhere, linked from the registry). |
|
Every term that is defined in the did-v1.jsonld context file MUST be defined in the registry... those terms might point to did core, and other places, if the term is defined normatively in DID Core, a link to this definition MUST be provided in the registry. @rhiaro is this consistent with your view? |
Not quite. Every term in the did-v1.jsonld context fill will be in DID Core. There won't be any terms defined elsewhere. Extensions will have their own jsonld contexts. |
|
@rhiaro 90% of did-v1.jsonld relies on w3id.org for vocabulary: https://github.com/w3c/did-core-registries/blob/master/contexts/did-v1.jsonld#L8 That is not going to change (it would break everything, see #21). What could change is that the registries could define these terms, and did core html could define some of them, but I would expect did core html to never define all of them, because that didn't happen in the VC Data Model, and we are light years away from covering all of did-v1.jsonld in the did core spec today, and its looking like there would be major objections to doing that.... DID Core Registries term definitions ( JSON-LD + Schema + HTML ) is a strict superset of DID Core HTML term definitions. For all properties defined in DID Core, there will exist an entry in the registry accounting for representations. Some properties in DID Core Registries will not be mentioned in DID Core (IE, there will exist JSON-LD definitions, that are not reflected in DID Core, as is the case today, with almost all of the terms defined in w3id.org... Signature Suites being a prime example). @msporny @selfissued is this your understanding as well? I'm trying to get this storing of normative statements issue unblocked. Do we have consensus on:
|
Ah okay, my understanding from talking to @msporny about this was that the terms from the security vocab which are depended on by the DID Spec will be defined in the DID Spec eventually, since they are not normatively defined anywhere else at this time. We can't really use the registry to define core terms and depend on it normatively from the DID Spec, because it's a non-normative document, whether it ends up as a NOTE or a CG report or something else. |
|
yes, we can't make any normative definitions in the registries. but we can point to normative definitions that exist in did core spec, if they exist. |
|
Right. And for the core context, they need to exist there. Otherwise they are defined normatively nowhere, and therefore essentially not part of the spec at all. |
|
I suggest closing this issue, and opening a new issue to track subsequent changes to how terms are registered. |
|
As discussed on the call 7-27, this has been done. Any further recommendations for changing how the registry handles these properties should be handled in a new issue. |
|
The issue was discussed in a meeting on 2021-07-27
View the transcript3.4. Storing normative properties? (issue did-spec-registries#9)See github issue did-spec-registries#9. Orie Steele: I believe we resolved this as well, we re-structured the way the registry defines terms in DID Core, the way the registry lists properties of the abstract data model, properties of representaions, properties of extensions are all defined in DID Spec registries... I think this is done, however, we did spend a lot of time talking about this particular issue. I wonder if folks are happy w/ the way things ended up. Manu Sporny: +1 to close and say new issue for new suggestions
|
The current draft contains definitions for
idas well as forpublicKeys. But these are special, insofar as these properties are defined by the DID Core document and are, therefore, normative. This means that their specification are part of the abstract data model in the Core document, and their representations in JSON, JSON-LD, and CBOR are part of the standard.Whilst they should appear in, say, the JSON-LD context and the JSON schemas, the registry document should make it clear that they are not defined in this document. This is a difference between these and any property or, to use an example in the document, any specific keys (like
Ed25519) that are not normative in the sense that they are (I presume) not normatively defined in the DID core document. The essence of the registry is to allow the community to add extensions, i.e., non-normative keys, values, whatever.It may be a better way to:
The text was updated successfully, but these errors were encountered: