Normative guidance regarding @context is not clear

[OR13]

The value of the @context property MUST be an ordered set where the first item is a URL with the value https://www.w3.org/ns/credentials/v2. For reference, a copy of the base context is provided in Appendix B.1 Base Context. Subsequent items in the array MUST express context information and be composed of any combination of URLs or objects. It is RECOMMENDED that each URL in the @context be one which, if dereferenced, results in a document containing machine-readable information about the @context.

• https://w3c.github.io/vc-data-model/#contexts

However, the current context that is resolved contains non normative members and data integrity proof specific values:

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2

This makes the guidance to implementers ambiguous.

This is one of several issues I am filing related to the discussions on:

#1082

I propose the following:

1. The v2 context only contain JSON-LD terms definitions for "JSON Members" that are normative, in the core data model.
2. The v2 context should not contain definitions for "reserved" or "proposed" terms, I am happy for those to also be hosted by W3C though, perhaps in a new context for "experimental features", @msporny had proposed something similar previously.
3. The W3C vocabulary for VCs should define only normative terms, it does not need to "reserve URLs" when their meaning is not yet established by the group, for this case, the correct term URL is the "issuer dependent one" since the issuer has no other reference to use.

[iherman]

I repeat some of the points I made in #1093

The @context file does not define anything whatsoever. The term in question is defined in the VCDM specification and the VCDM vocabulary document. In the sense of the specification, the @context file is merely a helpful tool for JSON-LD implementers to make it sure that when they use the JSON key termOfUse, they indeed use the one the WG has agreed upon. Fundamentally, that is al it does. If the item is removed from the @context, by virtue of the @vocab that we introduced in @context, the term will instead be turned into https://www.w3.org/ns/credentials/issuer-dependent#termOfuse, which is not what we would want.

In short, we are focussing on the wrong target: specification purity should not target at @context, which is "just" a fancy (though complex) mapping procedure between the cornerstones: the vocabulary specification and its representation in JSON-LD.

(This actually raises the question whether the vocabulary document should be normative or not. The answer is probably not, but that is a separate discussion.)

[OR13]

@iherman there has been a resolution by the working group that the "base data model" is vc+ld+json AND this normative sentence I quote above.

The core spec also intends to assume compact representations, which means the term URLs will never be seen by implementers until they apply the context (which they are not required to do, UNLESS they use data integrity).

Implementers are required to apply the context or consider it when performing ANY mapping AND when signing AND verifying with data integrity.

In short, if the value of the @context is not relevant to VC Data Model issuers and verifiers, then it should be removed from the spec (I don't think this is the case), if implementers MUST understand it, it should be normative ( and it should be minimized ).

In my opinion, implementers MUST understand it, given the current discussions regarding registering reserved terms, you have argued this exact point when you mention that @vocab is an "issue", yet that term only shows up in @context.

It could be the case, that some of these normative statements regarding "W3C Verifiable Credentials" ONLY apply to certain proof formats.

If that IS the case, those normative statements belong in:

https://www.w3.org/TR/vc-data-integrity/

NOT in:

https://www.w3.org/TR/vc-data-model/

It is my assertion that the v2 context values are NOT required to be understood by implementers producing VC-JWT, (the URL values is however)... Perhaps this is not true of "native token vcs" where the mapping must be defined, but that is a separate matter.

Is it currently your assertion that the v2 context values are not required to be understood by implementations producing conformant data integrity proof?

Can you explain how the n-quads that are signed don't need the v2 context (value) in order to exist?

Can you explain how the n-quads that are verified don't need the exact same v2 context (value) in order to exist?

Perhaps the assertion you are making here is that JSON-LD operations are an implementation detail?

IMO, if this is true, the core data model is actually application/json.

[iherman]

@iherman there has been a resolution by the working group that the "base data model" is vc+ld+json AND this normative sentence I quote above.

The core spec also intends to assume compact representations, which means the term URLs will never be seen by implementers until they apply the context (which they are not required to do, UNLESS they use data integrity).

Implementers are required to apply the context or consider it when performing ANY mapping AND when signing AND verifying with data integrity.

We agree on this.

In short, if the value of the @context is not relevant to VC Data Model issuers and verifiers, then it should be removed from the spec (I don't think this is the case),

I do not think it either, and I never said it.

if implementers MUST understand it, it should be normative

That is a separate issue, and I am neutral about it. If it helps implementers to have it as normative, I do not mind. But having the @context be normative does not mean that all the mapping results in it are necessarily normative, ie, that all terms it maps to a URL are normatively specified. That latter seems to be your conclusion.

( and it should be minimized ).

I am not sure what "minimized" means. You have made an additional statement here which is open for interpretation.

It could be the case, that some of these normative statements regarding "W3C Verifiable Credentials" ONLY apply to certain proof formats.

If that IS the case, those normative statements belong in:

https://www.w3.org/TR/vc-data-integrity/

NOT in:

https://www.w3.org/TR/vc-data-model/

That is actually a separate issue again. And I actually believe that the same mechanism on "experimental" terms may have to be added to the DI specification as well, but that is a discussion for another day.

It is my assertion that the v2 context values are NOT required to be understood by implementers producing VC-JWT, (the URL values is however)... Perhaps this is not true of "native token vcs" where the mapping must be defined, but that is a separate matter.

I think that is again a separate question, which is independent of the discussion point at hand.

Is it currently your assertion that the v2 context values are not required to be understood by implementations producing conformant data integrity proof?

Strictly speaking: a v2 @context is required, and we have decided to produce the current @context for the purpose of this specification. It would be perfectly possible to produce a different @context that produces the exact same set of n-quads from exactly the same Verifiable Credential instance encoded in JSON-LD. Just as the same specification can be implemented by two different programs using the same programming language producing exactly the same, conformant results.

Can you explain how the n-quads that are signed don't need the v2 context (value) in order to exist?

See above.

Can you explain how the n-quads that are verified don't need the exact same v2 context (value) in order to exist?

See above.

Perhaps the assertion you are making here is that JSON-LD operations are an implementation detail?

IMO, if this is true, the core data model is actually application/json.

This is not my assertion.

I fail to understand how all these questions and statements answer to the issues I raised.

[msporny]

1. The v2 context only contain JSON-LD terms definitions for "JSON Members" that are normative, in the core data model.

-1

Counter-proposal: The v2 context will contain JSON-LD terms definitions for all normative and reserved properties in the core data model.

2. The v2 context should not contain definitions for "reserved" or "proposed" terms, I am happy for those to also be hosted by W3C though, perhaps in a new context for "experimental features", @msporny had proposed something similar previously.

-1

The "experimental features" proposal I made was to have one context with @vocab -- that proposal doesn't apply to this issue.

Counter-proposal: The v2 context will contain JSON-LD terms definitions for all normative and reserved properties in the core data model.

3. The W3C vocabulary for VCs should define only normative terms, it does not need to "reserve URLs" when their meaning is not yet established by the group, for this case, the correct term URL is the "issuer dependent one" since the issuer has no other reference to use.

-1

@mprorock provided a table with definitions, which seemed to have support on the call yesterday. Those definitions can be used in "experimental" properties in the W3C VC Vocabulary. If we are going to reserve properties, we need to say what their expected usage is going to be.

Counter-proposal: The W3C VC Vocabulary will contain definitions for all normative and reserved properties in the core data model.

[OR13]

Very related #1103

[iherman]

Counter-proposal: The W3C VC Vocabulary will contain definitions for all normative and reserved properties in the core data model.

More exactly: normative, reserved, and deprecated.

It is perfectly possible to mark each term (class or property) as 'reserved' (or 'deprecated') and this extra "metadata" will be apparent in the resulting JSON-LD/Turtle and HTML representation. (In fact, this is a feature of yml2vocab that has already been implemented...).

[shigeya]

I have a question.

Counter-proposal: The W3C VC Vocabulary will contain definitions for all normative and reserved properties in the core data model.

More exactly: normative, reserved, and deprecated.

Does this mean only predefined normative, reserved, and deprecated definitions?

@OR13 used the word only, but @msporny rephrased "will contain," so I could read it may include other words. On the contrary, @iherman wrote, "More exactly".

[OR13]

Core data model doesn't reference term definitions, but context and vocabulary contains them.

The working group is going to end up misleading implementers on normative requirements, and it will lead to formal objections.

Compact JSON-LD doesn't have term definitions, if they need to be understood, they need to be normative, and the working group will need to make the context and vocab normative.

[iherman]

@shigeya:

@OR13 used the word only, but @msporny rephrased "will contain," so I could read it may include other words. On the contrary, @iherman wrote, "More exactly".

My comment was meant to point out that the vocabulary definitions also includes a number of deprecated terms. These terms are in the vocabulary (it is still under discussion whether the vocabulary would be normative or not) because they may have been in use for several years, and we cannot therefore "just" remove them.

[OR13]

We can just remove them.

However, we might not get consensus to just remove them.

[brentzundel]

@OR13 would this be addressed if #1158 is merged?

[OR13]

Yes

[OR13]

I created #1185, I think this issue can now be closed.

[iherman]

The issue was discussed in a meeting on 2023-07-05

• no resolutions were taken

View the transcript

2.10. Normative guidance regarding @context is not clear (issue vc-data-model#1090)

See github issue vc-data-model#1090.

Orie Steele: saddly not enough.

Manu Sporny: Brent said this should be addressed if PR 1158 is merged. Orie agreed.

Orie Steele: It answers the question about the literal @context value being normative. It doesn't say what to do with the value.
… We could close this issue.
… But we need to explain why we made @context normative.
… Documents are compacted by default. Expanding is something you do with @context.
… We should be clear on what processors do and what to do if errors occur when processing.

Michael Jones: Orie and friends, is there an issue to mark that we do need to describe what you do with @context, and if not, can one be filed?

Orie Steele: I think there is not one that addresses it directly...

Kristina Yasuda: We could leave this open or file a new issue.
… What do you want to do, Orie?

Orie Steele: I will file a new issue and mark this one pending close.

[brentzundel]

No objections raised since marked pending close, closing.