-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON-LD Contexts in Registry #202
Comments
related: w3c/did-spec-registries#3 |
It is not permissible to include a property in a did document that has an We have CI Tests for this in the did core registries now. Im not sure what to do with this issue. |
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 |
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. |
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. |
What language needs to be updated for JSON-LD consumers? Currently it says the value of |
I'd say it should be recommended that the 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: |
yes, spec already says that too |
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. |
The current text in the spec is:
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:
|
I am good with @dlongley 's proposed language here, adapted to both the producer and consumer sections of 6.2. |
@dlongley please raise a PR for this! |
See PR #362. |
I will look into resolving the conflicts and looking at the comments on #362. |
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 text was updated successfully, but these errors were encountered: