Section 4.1 Context

[nadalin]

There is no reason to have the @context this should removed or at least made optional. @context is not needed when suing JWT or even CWTs as claims

[nadalin]

There is no reason to have the JSON-LD Context mandatory, this could signify that JSON-LD was being used and not JWT/CWT but not required when having a JWT/CWT Claim. There is no reason to have to parse a JSON-LD @context statement to get to a JWT/CWT structure. Making JSON-LD optional allows for more widely used claims, also will allow for a JWT to contain an Access Token for any authorization that may need to take place.

Using JWT/CWT will expedite the roll-out of VC since there are already implementations at thousands of RP out there and many open source client libraries for verification and encryption.

[brentzundel]

There is nothing (to my knowledge) in the data model that prohibits the use of JWT or CWT.
The requirement of a @context property does not limit an implementer to JSON-LD, nor is there a requirement that any @context be parsed. The property must simply be present.
My understanding of why this is so, is to increase potential interoperability between JSON-LD and other JSON types. I believe that having the @context property present does not break a standard JSON parser, but not having the property could break a JSON-LD parser, and there are several implementers who are planning to use JSON-LD.
It is entirely possible that I have misrepresented the facts here due to a misunderstanding on my part. I look to @msporny or @dlongley or others to correct me if I am mistaken.

[David-Chadwick]

I think this issue should be linked to #474 and clarifying text added to the spec for both properties.

[nadalin]

We have implemented w/o the use of @context, there is absolutely no need for the @context in most cases, I don't understand the requirement here, this should be optional nit mandatory, you don't need this if using JWT yet it is required.

[chaals]

@nadalin:

I don't understand the requirement here

That's OK - strictly speaking it is not necessary to understand.

That said, as @brentzundel said above. If you have the @context token then JSON-LD processors (there are several) can do more useful reasoning over the credential, e.g. for managing them, or extensibility. Meanwhile, it has no more practical impact on simplistic tools that don't use it than the rest of the syntax requirements imposed by using JSON.

[nadalin]

@chaals ok, so don't force to be mandatory @context as it's not always needed, as it complicates processing when really not needed in all cases

[chaals]

Any time interoperability with those who are doing JSON-LD processing is needed - i.e. for a valid credential that you want to share outside a walled garden - @context is necessary. The same as any time interop with JSON processors is needed, getting the commas and braces right is necessary.

I don't understand how a token that you recognise but don't process complicates processing. This is a really common pattern to support interoperability.

[nadalin]

There is abosolltly no need for the @context when using a JWT that we have seen in our implementations. so if you are using JSON-LD this could be required but not when using JWT/CWT, If i'm processing a JWT I would not expect a @context, so this does not promote interoperability as there are libraries out there today that process JWT/CWT

[chaals]

@nadalin

There is abosolltly no need for the @context when using a JWT

Right. I believe everyone already knows that. You do understand that interoperability between libraries based on JWT and libraries based on JSON-LD needs @context, right?

The question I asked was if you could explain the complications for JWT processing when the @context token is present.

[nadalin]

The specification says that "The value of the @context property MUST be an ordered set where the first item is a URI with the value https://www.w3.org/2018/credentials/v1. Subsequent items in the array MUST be composed of any combination of URIs or objects that express context information. It is RECOMMENDED that dereferencing the URIs results in a document containing machine-readable information about the context."

So this puts extra burden on processing the @context when not even needed, this is also a possible security attack for retrieving a remote context. This does not say trhe @context can be null. it also says that you SHOULD defeference. uggg.

I have not heard why this is requires for JWT

[nadalin]

This is how I would see a simple JWT based verifiable crefdential to look like and not have to process/parse the @context
{
"sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "http://example.edu/credentials/3732",
"iss": "did:example:abfe13f712120431c276e12ecab",
"iat": "1541493724",
"exp": "1573029723",
"nonce": "660!6345FSer",
"vc": {
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSubject": {
"degree": {
"type": "BachelorDegree",
"name": "Baccalauréat en musiques numériques"
}
}
}
}

[brentzundel]

@chaals has already made the case for improved interoperability if @context is required to be present.

Your primary concern seems to be the additional (and unnecessary) processing burden for JWT implementations.
@nadalin, would this concern be as significant for you if the specification explicitly stated that even though the @context is mandatory, processing it is not?

[chaals]

@nadalin your proposal explicitly breaks interoperability with JSON-LD processing. That seems like a bad idea, and you still haven't answered the question of what problem you are solving in order to do so.

[chaals]

@nadalin

This does not say trhe @context can be null. it also says that you SHOULD defeference. uggg.

No, the @context cannot be null.

Where does it say that you should dereference it?

[nadalin]

@chaals see "ntext
The value of the @context property MUST be an ordered set where the first item is a URI with the value https://www.w3.org/2018/credentials/v1. Subsequent items in the array MUST be composed of any combination of URIs or objects that express context information. It is RECOMMENDED that dereferencing the URIs results in a document containing machine-readable information about the context"

[nadalin]

@chaals The issue I'm solving is that there are so many deployments of JWT/CWT and very few in comparaison of VC and thus i'm making it simple to use JWT and actually have a proof mechanism that is deployed and used by almost every RP out there today, so JWT/CWT should be the default and if you need JSON-LD thats fine but not force it as it breaks every JWT/CWT processing library out there, no need to do that at all if you are looking for wide deployment and interoperability

I don't see a requirement for force JSON-LD on everyone

[dmitrizagidulin]

@nadalin

The issue I'm solving is that there are so many deployments of JWT/CWT and very few in comparaison of VC

If we're going by that logic, the use of @context on the web (for various claims using Schema.org) is overwhelmingly larger than the use of JWTs, by at least one order of magnitude. To put it another way, @context is used and understood by every major search engine, including Bing, and JWTs are.. not.

if you need JSON-LD thats fine but not force it as it breaks every JWT/CWT processing library out there

Let's be clear here, this is emphatically NOT the case. Including a @context property in a JWT in no ways breaks any JWT processing library (I speak from experience here, having been involved in the implementation of several JWT processing libraries).

[nadalin]

@dmitrizagidulin You seem to have missed the point, my proposal is to make a VC a JWT not to encapsulate the VC inside a JWT

[chaals]

@nadalin

my proposal is to make a VC a JWT not to encapsulate the VC inside a JWT

So the outcome of such a proposal would be:

Instead of having a format that is compatible with both JSON-LD, which has serious deployment and widespread use and solves some of the internationalisation issues we would otherwise have, and with JWT which has serious deployment and widespread use and no solution for some internationalisation issues we continually see, we would now make VCs incompatible with JSON-LD and those who use it.

This will save us from a small amount of syntax that can easily be treated as a simple token.

I certainly fail to see any useful point of such a move - although I can see a clear cost in interoperability, and fitness for purpose as a global standard.

[nadalin]

@chaals Proposal actually provides a standard signature specification and no need for C14N which JSON-LD does not provide.

[brentzundel]

@nadalin this issue was raised to bring up certain points about contexts, specifically:

1. "There is no reason to have the @context this should removed or at least made optional."
2. "@context is not needed when suing JWT or even CWTs as claims"
3. "There is no reason to have the JSON-LD Context mandatory"
4. "There is no reason to have to parse a JSON-LD @context statement to get to a JWT/CWT structure."

Each of these points has been addressed:

1. " interoperability between libraries based on JWT and libraries based on JSON-LD needs @context"
2. True
3. " interoperability between libraries based on JWT and libraries based on JSON-LD needs @context"
4. "The requirement of a @context property does not limit an implementer to JSON-LD, nor is there a requirement that any @context be parsed."

You then propose: "to make a VC a JWT not to encapsulate the VC inside a JWT"
While pursuing such a proposal certainly would make @context unnecessary, it is not actually related to the issue and points you raised, and if you wish it to be considered by the working group, I highly recommend raising another issue with that proposal.

As far as this issue is concerned, I believe your points have been addressed. If there is a point related to this issue that has not been addressed, please let us know.

[nadalin]

@brentzundel

1. Don't understand, as JWT libraries don't need @context so I think you mean that JSON-LD libraries need the @w3c/qt3tests-editors
2. See Nesting Signatures with JWT #1
3. The document says its recommended that you de-reference the @context statements, thus it is required unless you remove that requirement

So no issues have not been addressed

[stonematt]

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

RESOLUTION: The VCWG had considered all points raised by issue #483 throughout the lifetime of the WG's operation, no new information was provided by issue #483 to convince the WG to change @context being mandatory (which has broad support in the WG with no objections). The WG will provide non-normative changes to the specification to clarify when and how @context should be processed and that "JSON-LD processing" is optional.

[msporny]

A non-normative PR #535 has been merged in an attempt to address the reviewers concerns. The PR is the only change approved for the specification for this issue and thus processing of this issue is complete. I expect PR #539 will also help with this issue, but that PR is being applied to other issues as well.