Did-core: JSON-LD Contexts in Registry

[jricher]

One of the discussed features of the DID property registry is that it would contain JSON-LD contexts for all defined properties. When producing a JSON-LD representation of a DID document, is it then permissible to include a value for the context that is not in the registry?

Note that local agreements can always allow whatever contexts they want, but for a globally interoperable DID document, I think we need to limit it to the contexts that are defined in the registry.

[OR13]

related: https://github.com/w3c/did-core-registry/issues/3

[OR13]

It is not permissible to include a property in a did document that has an @context that is not defined in one of the contexts listed... if you are having trouble getting a property into the did core registries, you should self host a context definition that makes what you are doing valid.

We have CI Tests for this in the did core registries now. Im not sure what to do with this issue.

[kdenhartog]

I felt like the statement "Unknown object member names MUST be ignored as unknown properties. " accurately addressed this concern in section 8.2.2.

My interpretation of this was that, yes it's acceptable to include the values, but from a global point of view they should be ignored. If two parties choose to support a private party, then I would consider it acceptable but discouraged. Essentially treating it like private headers in JOSE.

Looks like the spec expects that we'll have additional details provided based on the discussion in #205 as well

[OR13]

We're waiting for some html / structure updates to: https://github.com/w3c/did-spec-registries

We need to update the consumer language for JSON-LD.

[jricher]

I believe we need to update the consumer language for JSONLD in the Representations section to represent the behavior of the did-spec-registry for JSONLD contexts.

[rhiaro]

What language needs to be updated for JSON-LD consumers? Currently it says the value of @context must be one or more URIs. Do we need more than that? There is no restriction on what these URIs should be, nor is there any special behaviour related to the Registries, as far as I know.

[OR13]

I'd say it should be recommended that the @context if present be an array, and that the first element be the latest published context url, for example: https://www.w3.org/ns/did/v1.

While there are no restrictions (and I think thats probably best), we should make sain default recommendations, that if followed will enable general interoperability... see also:

https://github.com/w3c/did-core/issues/55#issuecomment-646727261

[rhiaro]

I'd say it should be recommended that the @context if present be an array, and that the first element be the latest published context url, for example: https://www.w3.org/ns/did/v1.

yes, spec already says that too

[dlongley]

@jricher,

One of the discussed features of the DID property registry is that it would contain JSON-LD contexts for all defined properties. When producing a JSON-LD representation of a DID document, is it then permissible to include a value for the context that is not in the registry?

Note that local agreements can always allow whatever contexts they want, but for a globally interoperable DID document, I think we need to limit it to the contexts that are defined in the registry.

The short answer to the above is "yes, what you said": that contexts that are not in the registry should be permitted, but for a globally interoperable DID document, you must only reference contexts that are defined in the DID spec registries. I will try to figure out where to add language of this sort. Would that be sufficient to close out this issue -- and, @OR13, does this sound problematic to you for any reason? This issue sounds like it's not about properties within a context, but rather, the actual contexts that are referenced. Within a context, we can refer to the JSON-LD spec for what is valid.

@jricher -- you mentioned that we "need to account for producer / consumer language on the call today". Is something along the lines of the above heading in the right direction or did you want more details? If you want to wait to respond to concrete language, that's fine, just trying to ensure we're not missing something else that you were looking for.

[dlongley]

The current text in the spec is:

The value of the @context property MUST be one or more URIs, where the value of the first URI is https://www.w3.org/ns/did/v1. All members of the @context property MUST exist be in the DID properties extension registry.

I agree with the first sentence and think we have consensus on it. The second sentence is what may need nuance for global interoperability. Perhaps something like:

All members of the @context property SHOULD exist in the DID properties extension registry in order to achieve interoperability across different representations. If a member does not exist in the DID properties extension registry, then the DID Document will not be interoperable across representations.

[jricher]

I am good with @dlongley 's proposed language here, adapted to both the producer and consumer sections of 6.2.

[OR13]

@dlongley please raise a PR for this!

[dlongley]

See PR #362.

[dlongley]

I will look into resolving the conflicts and looking at the comments on #362.