5.3.1 Semantic Interoperability

[nadalin]

No need to process the @context unless dealing with JSON-LD, should be made optional

[nadalin]

JWT/CWT are deployed widely in the web, most every RP uses these, so I don't think this should be at risk, what makes this at risk is that these are not first class objects that is they are always within a JSON-LD container, so if that restriction is removed then I think you would see JWT/CWT be widely used instead of JSON-LD. Microsoft is using JWT/CWT

The use of an IANA registry for the various JWT claims would serve the purpose that the @context does unless I'm missing something here

[brentzundel]

It is my understanding that processing the @context is optional, even though the property is required to be present.

[nadalin]

It says "It is RECOMMENDED that dereferencing the URIs results in a document containing machine-readable information about the context. " it also says that the @context value pair MUST be there, no reason for this other than to force JSON-LD IMHO

[brentzundel]

There are comment in #483 that I believe are pertinent to this issue as well.

[David-Chadwick]

@nadalin "The use of an IANA registry for the various JWT claims would serve the purpose that the @context does unless I'm missing something here". What you are missing is that VCs are built on an open model, meaning that anyone is free to extend VCs in any way that they want to – “permissionless innovation”, without the need for a centrally managed registry.

[nadalin]

@David-Chadwick There is no requirement in the spec to be decentralized that I can find, there are already dependencies on DNS with JSON-LD and dependencies on registries in this specification so IANA is just fine since the algorithm identifiers are defined in IANA

[dmitrizagidulin]

@nadalin Nobody is forcing JSON-LD processing on anyone. Yes, @context is required, for wider interop.

JWT/CWT are deployed widely in the web

The use of @context on the web is at least one order of magnitude (if not more) greater than the use of JWT. It is literally used by billions of web pages, by every major search engine, including by Microsoft's Bing.

The 'RECOMMENDED that dereferencing the URIs results in a document containing machine-readable information' is just developer courtesy and common sense, but it is still not forcing anything. Your implementation is still free to break interop and not have a derefernceable URI.

[jandrieu]

@context is mandatory, as per the discussion and consensus at the Barcelona face-to-face meeting.

@nadalin, including the @context means interoperability for JWT and JSON-LD. It doesn't mean you must use JSON-LD, just that you are conformant to a spec that supports interoperability.

[chaals]

It is RECOMMENDED that dereferencing the URIs results in a document containing machine-readable information about the context

doesn't imply you need to process anything. It merely means that best practice (in order to support the tools that do use JSON-LD) is to have the URL in the @context property actually dereferenceable, and provide a context file as describe by JSON-LD.

As noted above, you're not actually forced to implement best practice, let alone Process the @context section.

On the other hand I would note that there are internationalisation issues that are almost impossible to solve without either using JSON-LD or copying the features directly into the VC spec and requiring all processors that don't have JSON-LD to adopt the functionality. (This is a common problem with JSON-based specs, by the way).

[David-Chadwick]

@nadalin "The use of an IANA registry for the various JWT claims would serve the purpose that the @context does unless I'm missing something here". What you are missing is that VCs are built on an open model, meaning that anyone is free to extend VCs in any way that they want to – “permissionless innovation”, without the need for a centrally managed registry.

[David-Chadwick]

This might be slightly off topic, but I note that Microsoft are now using @context in their Identity Hubs, see
https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Identity-Hubs-as-personal-datastores/bc-p/390930#M984

[nadalin]

@David-Chadwick JWT are open, nothing is mandatory like VC (making @context Mandatory) so a JWT is fully open to extend, VC seems also to have a dependency on https://w3c-ccg.github.io/vc-status-registry/ so not sure how you say that there is no central registry dependency

[David-Chadwick]

@nadalin There is no dependency on the status registry, and indeed, no requirement to publish the status, or even revoke VCs. Short lived non-revocable VCs are perfectly acceptable.
As to DNS dependency, the entire Internet is dependent on this, so this is a feature of all Internet applications rather than a particular dependency of VCs

[nadalin]

@David-Chadwick The same is true of JWT, you don't need to define anything in IANA. I was pointing out that you said you want non-centralized, and I'm pointing out as long as you use DNS you can't achieve that goal.

[msporny]

@nadalin This topic has been discussed at depth in the VCWG (and for many years before it). There is a simple table that summarizes what is and isn't possible w/ JSON+JWT and JSON-LD+JWT and JSON-LD+LD-Proofs here:

https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs

The thread so far in this issue has touched on a few of them, but there are more at the link above. I suggest you familiarize yourself with those arguments as there are seven points that you will have to argue against to convince the group that @context is not necessary for semantic interop (or that JSON or JWTs provide semantic interop by themselves, which they do not).

To put it another way, full JSON-LD processing is not necessary for implementers.

However, if you want your JSON-based implementation to support semantic interop, your JSON-based implementation MUST process @context by doing a string compare of the values in the array. Note that this is not JSON-LD processing, it is merely doing a strcmp on the @context array. If you don't do that as a JSON-based processor, you are not capable of supporting interop. If you want to assert something to the contrary, you will have to demonstrate how semantic interop is achieved with your alternative.

[nadalin]

@msporny I'm fully aware of table, there is NO REASON to require the @context when using JWT, it's simply not used or required. Please explain why the @context is needed

[msporny]

@msporny I'm fully aware of table, there is NO REASON to require the @context when using JWT, it's simply not used or required. Please explain why the @context is needed

If you have a JWT, let's call it jwt, and it contains a vc entry per the spec. If company A produces a JWT with an attribute like so - jwt.vc.credentialSubject.foo and company B produces an attribute like so - jwt.vc.credentialSubject.foo... without @context, there is no way for company A to know if company B is using foo in the same way or in an entirely different way without using some sort of out-of-band human-readable mechanism.

Using pure JWTs don't address that problem. Including @context does address that problem.

To be clear, you don't need to have @context at the top level of the JWT (but it does need to be in jwt.vc), and you don't need to do JSON-LD processing to be conformant with the specification. We went to great lengths to ensure that developers that didn't want to use JSON-LD did not have to pull in a single JSON-LD library when using JWTs as a proof mechanism.

[nadalin]

@msporny The point is not to use the JWT as just a proof mechanism but JWT as VC and JWS/E for proof

[brentzundel]

Yes, that is possible now without changing the spec in any way.

…

On Tue, Apr 2, 2019, 07:34 Anthony Nadalin ***@***.***> wrote: @msporny <https://github.com/msporny> The point is not to use the JWT as just a proof mechanism but JWT as VC and JWS/E for proof — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#491 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ5VP4V2dkpZeWclUS6DBIVj2PTMbIXsks5vc1xOgaJpZM4cNRQb> .

[nadalin]

@brentzundel no its not the spec has to be clear and it has to be documented on how to use a JWT as a VC in such a way it does not break JWT processors

1. No JSON-LD with-in a JWT
2. must use JWS/E for proof
3. No processing of @context if found as JWT parsers will not process what they don't understand

[msporny]

Het @nadalin, yes, good -- thank you for the concrete set of changes that you are seeking, we will put this forward in the group for discussion:

1. No JSON-LD with-in a JWT.
2. Must use JWS/E for proof.
3. No processing of @context if found as JWT parsers will not process what they don't understand.

[stonematt]

VCWG Teleconference Resolution: https://www.w3.org/2019/04/09-vcwg-minutes.html#resolution01

RESOLUTION: Processing @context for both JSON-based and JSON-LD-based processors is vital to ensure semantic interoperability. The VCWG has considered the points raised in issue #491 and has determined that no new information has been provided with regard to the topic of semantic interoperability. Additional non-normative text should be added to the specification to underscore why not comparing the @context against known values when using JSON processors leads to semantic ambiguity.

[msporny]

PR #546 implements the addition of non-normative text wrt. the resolution above. After that is reviewed and merged, this issue will be closed.