Align JWT/JWS fields with IETF RFCs.

[msporny]

This PR attempts to address issue #1275 by aligning the JSON-LD Context definitions in the base context with the IETF JOSE RFCs. The PR does this by allowing kid, iss, sub, and aud to be strings (they were previously limited to only being URLs).

[OR13]

This breaks the Verifiable Credential Graph as described in the data model.

It causes edges and nodes to be formed in RDF that are not as the issuer, holder, verifier expects when reading the specification, and it destroys conceptual alignment with data integrity.

This PR and the associated issue should be closed, without taking any further action.

[peacekeeper]

This breaks the Verifiable Credential Graph as described in the data model.

@OR13 I'm curious if your concern is about changing the definition of the terms to allow strings, or if it is about about having them in the context at all?

[OR13]

My concern is that 'iss' and 'issuer' are both identifiers that can be nodes or edges in RDF.

In general, the purpose of a shared graph data model is to be able to reason consistently from analyzing large data sets.

For example all identifiers that attempted to purchase alcohol from a specific location.

Both the location and the identifier for the subject will show up in the graph, regardless of the RDF shape.

In the case that you wanted to analyze related key material or other commonly understood claims, you would want them to have a specific shape in RDF, and then count occurrences, or apply other more advanced graph algorithms.

I don't think it's a good idea to make these claims not work correctly for JOSE or COSE but have them work correctly for data integrity proofs.

This applies to how proofs connect verifiable credentials to controller documents, or other identity representations.

However, in the case that there were no mapping in the common context, perhaps it's possible that a proprietary mapping might occur, and become the industry standard for analyzing JOSE or COSE data sets as RDF graphs.

Transmute will formally object if the information model is positioned to make analysis of a specific securing mechanism less intuitive or useful in the final technical recommendation.

However, Transmute would not object, if the working group was instead only focused on defining a single securing mechanism, and making that securing mechanism favorable to graph analysis.

[iherman]

My concern is that 'iss' and 'issuer' are both identifiers that can be nodes or edges in RDF.

I am not sure I understand, @OR13, as I have the same question as @peacekeeper.

The statement above is correct. The problem is that there is a subtle difference between the semantics of the two properties: the object in the corresponding triples can be a literal for iss and can only be a bona fide URL for issuer. These are the facts as of today in the model. Nothing is "broken", it just means that the various analysis, that you describe, and that is based on the specification of those properties, must take this fact in account. The change in the context file only encodes this difference.

(Correction, b.t.w.: from a generic RDF point of view it is correct that any property identifier can also identify a node in the graph, but I do not think this is relevant for the VCDM. Both iss and issuer identify edges of the graph which "point" to objects.)

[msporny]

@OR13 wrote:

For example all identifiers that attempted to purchase alcohol from a specific location.
Both the location and the identifier for the subject will show up in the graph, regardless of the RDF shape.

Speaking as an organization that is working on exactly this use case (TruAge), placing data like this in a VC is an anti-pattern. Tracking of individuals without their consent is an anti-pattern... and even with their consent is a dubious value proposition. So, if this is the use case we're focusing on, I can say that we definitely do not want to enable this sort of ecosystem when it comes to age-gated retail purchases. We should be optimizing for privacy-respecting frameworks. Perhaps we should focus on a Supply Chain Traceability use case as that seems to be where this requirement is coming from.

In the case that you wanted to analyze related key material or other commonly understood claims, you would want them to have a specific shape in RDF, and then count occurrences, or apply other more advanced graph algorithms.

Yes, agreed. The issue is that JWTs are so general when it comes to what you can put in fields (effectively, any string will do), that you can't count on that behavior.

I don't think it's a good idea to make these claims not work correctly for JOSE or COSE but have them work correctly for data integrity proofs.

For some definition of "correctly". The JOSE specifications are clear that the fields listed in this PR are StringOrURI and what was there before only allowed URI, which meant that the VCWG was changing the definition of JOSE (which we don't have the authority to do).

Transmute will formally object if the information model is positioned to make analysis of a specific securing mechanism less intuitive or useful in the final technical recommendation.

I expect others would object that we're changing the foundational assumptions of JOSE. In any case, thanks for making your intent to formally object clear.

Here's what I expect to happen when Transmute formally objects: Evidence will be put forward that the VCWG decided to change the definition of JWTs w/o approval from the JOSE community, and with one of the Editor's for that specification (@selfissued) in support of this PR, and the objection will be overruled.

What I suggest we do in order to get some finality on this issue is to ask the JOSE WG if it's ok if we profile the JWT specification and disallow strings in kid, iss, sub, and aud. This would mean that strings are illegal in those places in VC-JWT and you can only use URLs there. If the JOSE WG is ok with that path forward, then we can close this PR and cite that the JOSE WG approved the profiling of JWTs in that way for VCs.

However, Transmute would not object, if the working group was instead only focused on defining a single securing mechanism, and making that securing mechanism favorable to graph analysis.

-1, we have implementers implementing JOSE-secured VCs and Data Integrity-secured VCs. We need to document both.

[decentralgabe]

as terms controlled by the vc-jose-cose work item, I align with @OR13's views, specifically

It causes edges and nodes to be formed in RDF that are not as the issuer, holder, verifier expects when reading the specification, and it destroys conceptual alignment with data integrity.

The terms must maintain conceptual alignment with data integrity.

[selfissued]

The kid, iss, sub, and aud paramters can be (and are) be strings without this PR being merged.

For instance https://cloud.google.com/enterprise-knowledge-graph/docs/overview uses values of these kinds as strings in their knowledge graph.

Orie's objections about this change excluding these terms from the knowledge graph seems to apply.

Therefore, I believe that this PR should be closed without merging.

[msporny]

@decentralgabe wrote:

The terms must maintain conceptual alignment with data integrity.

Why? vc-cose-jose specifically does not align w/ Data Integrity in so many ways. Why does kid, iss, sub, and aud need to align with Data Integrity over aligning with JOSE?

@selfissued wrote:

The kid, iss, sub, and aud paramters can be (and are) be strings without this PR being merged.

No, they can't, they'll be converted to URLs without this PR.

If this PR isn't merged, kid, iss, sub, and aud will be interpreted as URLs. Full stop. By not accepting this PR, you are profiling JOSE down to require kid, iss, sub, and aud to be URLs.

I'm trying to make sure the vc-jose-cose work item doesn't shoot itself in the foot here, but if the Editors of that spec really do mean to make kid, iss, sub, and aud to always be URLs, I won't stand in the way.

I'm marking this PR as pending close.

[decentralgabe]

@decentralgabe wrote:

The terms must maintain conceptual alignment with data integrity.

Why? vc-cose-jose specifically does not align w/ Data Integrity in so many ways. Why does kid, iss, sub, and aud need to align with Data Integrity over aligning with JOSE?

My concern is specifically with iss and sub since they have direct relation to the core data model. It seems that in constructing the credential graph, being able to show that these terms are closely related is of value.

Even if a JWS is used there is value in having its properties represented in the graph consistently across securing formats. From my (growing, but limited) understanding of the graph data model, and @OR13's comment (quote below), this is better served with the context as-is. If I have a misunderstanding here - please correct me.

In the case that you wanted to analyze related key material or other commonly understood claims, you would want them to have a specific shape in RDF, and then count occurrences, or apply other more advanced graph algorithms.

[msporny]

@decentralgabe wrote:
My concern is specifically with iss and sub since they have direct relation to the core data model. It seems that in constructing the credential graph, being able to show that these terms are closely related is of value.

Even if a JWS is used there is value in having its properties represented in the graph consistently across securing formats. From my (growing, but limited) understanding of the graph data model, and @OR13's comment (quote below), this is better served with the context as-is. If I have a misunderstanding here - please correct me.

It depends on what you're optimizing for here. There are two mutually exclusive optimizations that can be done with this particular issue:

1. Optimize for graph semantics.
2. Optimize for broad interop w/ JOSE.

By rejecting this PR, you are optimizing for item 1 above. By optimizing for 1, you are profiling iss and sub as used in JOSE from StringOrURI to only allow URI. Any string value such as "key-1" will be interpreted as a relative URL instead of a string. So, I expect vc-jose-cose will need some language warning people about always using full URLs or understanding that if they don't, a document-relative URL will be presumed for iss and sub.

IOW, your understanding is correct. My concern is that the decision just doesn't align with my understanding: that the majority of the JOSE community does not care if the graph semantics match up with other securing mechanisms (or JSON-LD or graph semantics in general) and would rather optimize for broad interop w/ JOSE.

[iherman]

The issue was discussed in a meeting on 2023-10-31

• no resolutions were taken

View the transcript

1.2. Align JWT/JWS fields with IETF RFCs. (pr vc-data-model#1325)

See github pull request vc-data-model#1325.

Brent Zundel: This one is not labeled pre- or post-CR. Manu raised, some approving and some objecting.

Manu Sporny: It is a pre-CR, we don't have a path, I marked it pending close. I think that's ok, the VC-JOSE-COSE authors have decided on a direction and that's that.

Brent Zundel: Ok, marked pending close, will close in 3 days after the seven day window is up. Any final comments?

Ivan Herman: None of the VC-JOSE-COSE people are around -- I'm fine pending close, but we may wait for them.

Brent Zundel: The people not around are the ones pushing to close it.

Ivan Herman: Ah, ok.

Manu Sporny: In addition, I raised the issue and the PR and I'm fine with closing the issue and the PR, immediately if we want.

Brent Zundel: I'll close it after the meeting.

[brentzundel]

Closing, as discussed in the meeting on 31 October.