Conformance requirements for normative context

[OR13]

@context value is now normative.

What should conformant processors expect regarding operation that apply the context.

Should jsonld.expand succeed?

If jsonld.frame fails, should a verify raise an error?

etc...

Its not clear why the value is normative, and what part of it, an implementer must understand to conform.

It seems like a few sentences about frame or expand would be enough to cover this.

[dlongley]

We already reference that @context is defined by the JSON-LD spec (https://w3c.github.io/vc-data-model/#json-ld) and that spec has its own conformance section. Talking about performing any JSON-LD-related transformations is something that would be done in other specs such as a data integrity cryptosuite spec. So, IMO, I think we're already covered for the core data model spec and can close this.

[OR13]

@dlongley I hope you are right, but I still don't understand what "validate" means in the core spec, for example if a validFrom date is a string, but not the one defined in the core v2 context, will ANY part of the core data model processing requirements throw an error?

Similar issue with @protected, although perhaps this applies to secondary contexts interacting with the primary one...

The core data model does not seem to require ANY operation that would actually apply the normative context, here is a short list of operations I would expect to be relevant:

• expand
• frame
• canonicalize

Given that this is the case and the context is normative, I don't really understand what a "conformant processor" is doing with the normative requirement... possibly nothing, in which case data integrity would have to comment on this, and not the core context.

[dlongley]

@OR13,

The core data model does not seem to require ANY operation that would actually apply the normative context...

I think that's right and has been a goal since 1.0. That's part of what the "Semantic Interoperability" section is about:

This specification ensures that "plain" JSON and JSON-LD syntaxes are semantically compatible without requiring JSON implementations to use a JSON-LD processor.

The point was to make all of the core data model requirements clear in the spec itself whilst being congruent with JSON-LD -- thereby not requiring any JSON-LD transforms to be performed to consume data from the core model. Then, while no transformations are required, they can certainly still be performed as needed for any other reasons, such as for producing or verifying data integrity proofs, using CBOR-LD, merging graph data, etc.

So to validate validFrom, an implementation just applies the rules from the data model spec (https://w3c.github.io/vc-data-model/#validity-period) -- and because VC implementations must also ensure that the context is as expected (https://w3c.github.io/vc-data-model/#contexts), this indirectly guarantees compatibility with any transforms someone might perform involving validFrom using a JSON-LD processor that actually "applies" the core context.

[OR13]

Concrete example, an issuer redefines a protected term in a second context, but doesn't actually apply the context when issuing a credential.

2 verifiers both receive the credential, and verify it successfully but one tries to store it as RDF and encounters the protected term redefined error... The other stores it as JSON.

I guess this highlights that this is a securing spec issue, not a core data model issue?

[dlongley]

@OR13,

Concrete example, an issuer redefines a protected term in a second context, but doesn't actually apply the context when issuing a credential.

2 verifiers both receive the credential, and verify it successfully but one tries to store it as RDF and encounters the protected term redefined error... The other stores it as JSON.

In order to process a VC as "plain" JSON, its contexts must be expected values:

JSON-based processors MUST process the @context key, ensuring the expected values exist in the expected order for the credential type being processed.

This means that the contexts are well-known and have been vetted at least once and either stored permanently or matched up against some expected content hash. It doesn't require that the processing software apply a runtime JSON-LD transform (nor even include a JSON-LD library as a dependency), just that the contexts have been previously vetted (perhaps involving a one-time use of a JSON-LD transform performed by a trusted party) and put into some allow list that the processing software uses.

I guess this highlights that this is a securing spec issue, not a core data model issue?

It is true that some securing mechanisms will automatically detect problems for unexpected (or unknown) contexts, but for others, if all of the contexts are expected / well-known (and therefore vetted), it isn't a requirement to run any transforms during the consumption or verification process.

[OR13]

it isn't a requirement to run any transforms during the consumption or verification process.

The value it provides only happens when it's processed, and we don't seem to have any requirement for it to ever be processed.

It feels like there should be at least some reason to use the context value, in the core data model.

I don't feel we are giving implementers of the core data model any benefits of JSON-LD over plain JSON.

... But I believe that to be a goal of the working group.

[dlongley]

I don't feel we are giving implementers of the core data model any benefits of JSON-LD over plain JSON.

... But I believe that to be a goal of the working group.

I think we are giving them the benefits -- but we're also allowing for interoperability when not all of those benefits are used.

Simpler technologies have fewer requirements for interoperability but also solve fewer use cases and often do not scale. More complexity enables more scaling but at a cost of greater requirements that aren't worth the effort if being part of a large, decentralized ecosystem isn't of interest. A goal of VCs is to build the biggest interoperable, decentralized ecosystem. This means trying to reduce the requirements as much as possible to enable more systems to interop and reuse technology -- even (and especially) when different peers make different use of the available benefits.

[OR13]

I appreciate your approval on the PR that defines registered claim names in the V2 context, that is exactly what allowing people to tap the benefits of JSON-LD while not forcing them to process JSON-LD looks like.

[TallTed]

JSON-based processors MUST process the @context key, ensuring the expected values exist in the expected order for the credential type being processed.

This means that the contexts are well-known and have been vetted at least once and either stored permanently or matched up against some expected content hash.

The quoted spec statement does not require that all @context values correspond to previously vetted (in any way) URIs, nor that they be permanently stored nor hash-matched. It only requires that the expected values exist in the expected order; it says nothing about unexpected values. If the former is what was intended, we have some (potentially breaking change) rephrasing to do.

[dlongley]

@TallTed,

Actually, I believe all of that text is being removed (PR #1182) and could instead end up (with changes) in an implementation guide instead. That would mean that the spec would formally require people to use the JSON-LD conformance section, but the implementation guide could say how that could be done just once by any trusted party to then enable the use of previously vetted, hashed and /or stored, and expected context values in simpler software.

[iherman]

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

• no resolutions were taken

View the transcript

#### 2.7. Conformance requirements for normative context (issue vc-data-model#1185) _See github issue [vc-data-model#1185](https://github.com/w3c/vc-data-model/issues/1185)._ **Orie Steele:** It is unclear to me whether implementors are ever required to process the context document directly. > *Dave Longley:* not sure what Orie wants... but this PR might be related to it or might resolve it?: [https://github.com/w3c/vc-data-model/pull/1202](https://github.com/w3c/vc-data-model/pull/1202). **Orie Steele:** It would be good to have an explanation of what implementors can rely on now that the context document is required. **Manu Sporny:** 1202 was an attempt to explain non-RDF processing. > *Orie Steele:* exactly. > *Orie Steele:* yes! talk about expansion and framing! show the value of JSON-LD... we all the see value of JSON I think. **Joe Andrieu:** +1 to explaining the value of JSON-LD. > *Orie Steele:* +1 need to clarify if the verifier needs to understand normative context. > *Brent Zundel:* +1 Joe. > *Manu Sporny:* +1 to JoeAndrieu, agree. > *Orie Steele:* I think we are on our way to saying that directly... in [https://github.com/w3c/vc-data-model/pull/1202](https://github.com/w3c/vc-data-model/pull/1202). **Joe Andrieu:** I think that if a party receives a VC, they can assume that their interpretation of the local names is the same. ---

[OR13]

main open question I have is if verifiers / validators need to understand the context.... in other words... the context is normative, but what actually happens if its "not understood" correctly... I feel our spec should have some text explaining this, given we made it normative.

Its sorta related to the request to clarify the "value of JSON-LD" vs the "value of only processing JSON".

[iherman]

The issue was discussed in a meeting on 2023-08-02

• no resolutions were taken

View the transcript

#### 2.6. Conformance requirements for normative context (issue vc-data-model#1185) _See github issue [vc-data-model#1185](https://github.com/w3c/vc-data-model/issues/1185)._ **Kristina Yasuda:** what should conformance processor expect regarding normative requirements for context. **Manu Sporny:** What would Orie like the specification to say? … We have this JSON-processing part of the specification, whereas this is specifically about JSON-LD features of JSON. > *Michael Prorock:* +1 orie. **Orie Steele:** We should describe that, when processing VCs as JSON-LD rather than plain JSON, you must use the context in a particular way. … Yes, that's basically it. We have this section now that says you can process core data model as JSON -- with context being normative, we should also describe "if you process as JSON-LD, this is why we made context normative, so you get other values expected" -- any application that uses `@context` would prove value of making `@context` normative. … Issuers/verifiers/holders why do they need same underlying value? It's what enables these other capabilities... if you go beyond traditional JSON, what should you get, we should make that clear to readers. > *Orie Steele:* don't make json processing PR bigger. > *Orie Steele:* please :). > *Michael Prorock:* [https://github.com/w3c/vc-data-model/pull/1202#discussion_r1273762313](https://github.com/w3c/vc-data-model/pull/1202#discussion_r1273762313). **Michael Prorock:** Comment made on JSON Processing PR -- maybe we should add corresponding section on JSON-LD... I think we should, I think that's what manu is saying, that's what Orie is saying... we're beating the "JSON Processing PR" to death... let's get a corresponding PR for JSON-LD Processing as well. **Kristina Yasuda:** Yes, separate PRs are fine, but it would be great if -- would like to see second PR in parallel to JSON Processing PR -- my concern was ... what's value of @context if pure JSON processing is possible, if that goes in, that addresses part of my concern... understand they don't have to go in same PR. **Orie Steele:** I agree with point on confusion, it is confusing to just have JSON Processing, but also have acknowledgement of `@context` values are normative... I understand why it is that way, I think that language is correct, but I think other people will be confused until they see these things side-by-side, and that's caused JSON Processing to take longer. I would prefer JSON Processing to go in, keeping both of them open, will make review really hard -- I. > *Manu Sporny:* would recommend merging JSON Processing PR -- then filing bunch of issues to come up /align from review process -- easier to reduce parallel places we're having conversations. **Manu Sporny:** +1 to what Orie and mikeP just said. > *Brent Zundel:* +1 to Orie. **Kristina Yasuda:** Ok, marking this as ready for PR. … agree that both have to happen. … next week is going to be discussion on test suite special topic call... main call will be issue processing. … Thanks all, see you next week. ---

[brentzundel]

It is my understanding that this issue will be addressed by the same PR that addresses #1227

[OR13]

possible to also relate to VerifiableCredentialGraph, which only shows up in the @context.

[iherman]

The issue was discussed in a meeting on 2023-09-06

• no resolutions were taken

View the transcript

#### 4.5. Conformance requirements for normative context (issue vc-data-model#1185) _See github issue [vc-data-model#1185](https://github.com/w3c/vc-data-model/issues/1185)._ **Manu Sporny:** oops new comments in the thread, will PR soon. **Orie Steele:** related to your last comment on processing the data model in JSON-LD, I think a quick sentence or two would be enough. i'll propose inthread. > *Ted Thibodeau Jr.:* also see [https://www.w3.org/TR/string-meta/](https://www.w3.org/TR/string-meta/). **Joe Andrieu:** I think it might be reductive to say it should never be used in `@context`s, there are places even in VC were it might make sense. ---

[msporny]

PR #1281 has been raised to address this issue. This issue will be closed once PR #1281 is merged.

[msporny]

PR #1281 has been merged, closing.