[Openid-specs-ab] Defining JWT Claims to represent W3C Verifiable Credentials objects
nadalin at prodigy.net
nadalin at prodigy.net
Fri Apr 9 15:48:02 UTC 2021
I agree with most of your points, as there are different processing rules for JSON-LD and JSON, the data models are also different. The processing of the JSON-LD proof I don’t think can actually be done due to the C14N rules around JSON-LD. Verifiable Credentials have certain processing rules, and how JWT claims get processed as Verifiable Credentials not as JWT claims. I don’t think that its appropriate to have either JSON-LD Claims or proofs represented in JSON.
This proposal does not give us anything but security issues and processing issues.
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of David Waite via Openid-specs-ab
Sent: Thursday, April 8, 2021 2:51 PM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: David Waite <david at alkaline-solutions.com>; oliver.terbu at mesh.xyz
Subject: Re: [Openid-specs-ab] Defining JWT Claims to represent W3C Verifiable Credentials objects
I would propose two new names, “jsonld” and “jwt”. The “jwt” claim exists for allowing for a payload with additional claims, which is not supported with nested JWTs, and for allowing for multiple JWTs to be nested inside one (which will have a space penalty).
Specifically for the “jsonld” case:
JSON-LD’s @Context is acting analogous to an XML namespace in the sense that it is defining a new axis for how properties should be interpreted, and without that additional context in mind the data cannot be interpreted as JSON. A non-cached JSON-LD Context document also allows for arbitrary redefining how the data should be interpreted as the context is changed on the network.
In this light, the reason to have a vc/vp claims is to isolate the rest of the JWT, which *does* have well-defined and static claim definitions, from the different set of rules that is the JSON-LD. IMHO, there are not enough security considerations around JSON-LD VCs and VPs to treat them as standard JSON data - you need to interpret that data as RDF in tooling.
Because of that, the security properties of a JWT should be declared as JWT claims. Merely treating a JWT as an envelope for delivering RDF data should not alter the security posture or interpretation of any other claim that is abiding by JWT rules (or rules of other similarly isolated claims like CNF). If there are properties which do not map from the VC/VP space which are necessary, they should have a JWT standard for them with IANA-registered claims or JOSE header values.
Once you strip VC/VP of those responsibilities, I suspect you are just doing one of two things:
1. Using JSON-LD as a way to pass RDF-defined attributes inside a JWT in an isolated manner. As an example, trying to (e.g.) define an @context for the root of the JWT payload to represent it as a VC or VC-adjacent RDF graph would put us in the same undesirable security posture as VCs with LD-Proofs are today - a single set of security-related data which can be interpreted in multiple ways by different tools. Those of us with XML battle scars know the sorts of ways implementers can mess this up, even _with_ properly declared security considerations. This was fixed in DIDs by having JSON and JSON-LD be considered separate formats.
2. Using a JWT as an envelop for LD-Proof signed JSON-LD data. This is appropriate for a verifiable presentation of say an RSA-based proof VC, where the presentation step is more about applying a proof-of-possession than doing any sort of manipulation (selective disclosure, ZKP proof)
I don’t believe _either_ of these are VC or VP related. I can see for instance lab results from SMART on FHIR being secured with one or both of these methods, for instance. We specifically don’t WANT to have JWT validation depend on the semantics of say an embedded VC/VP data set, nor do we want to limit people from having to work within the constraints of the VC data model in order to leverage these techniques.
Likewise, I don’t think the claim name should attempt to be a hint for the type of data contained within the claim, because the interpretation of that data is defined by JSON-LD and RDF rules.
Note however that there may be additional rules needed for processing the RDF data which are unfortunately not easy to define in either space.
For instance, it might make sense for a value like ‘sub’ or ‘jti’ or ‘iss’ to be treated as the base IRI of the RDF data, but _which_ one is appropriate (or even whether they are required to be declared as a URI value in the JWT claim) is not something we can specify.
Likewise, the VC data may still need to make sure the `sub` in the JWT is a URI which corresponds to the @id of the credentialSubject within the VC. Since the VC data is isolated from the JWT, this may lead for extra processing around the RDF data embedded within a JWT for VC/VP use cases.
On Apr 7, 2021, at 6:25 PM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net> > wrote:
In our discussions over the past few months, it’s become clear that there are multiple use cases where different forms of W3C Verifiable Credential objects will be communicated as JWT claims (or as UserInfo Endpoint claims). I had a useful conversation with Oliver Terbu and Kristina Yasuda this week during which we agreed that it would be useful to write a short, focused specification defining and registering JWT claims enabling standard representations for this purpose. These claims could be used both by SIOP use cases and other use cases.
Bear in mind that the W3C Verifiable Credentials specification defines two representations of the objects that it defines – JWT and JSON-LD and it also orthogonally defines two kinds of objects – Verifiable Credentials and Verifiable Presentations. Thus, there are actually four different data types that these use cases might want to utilize.
I would therefore propose the following four claim definitions for these purposes:
* vc_jwt: A claim whose value is a W3C Verifiable Credential object using the JWT representation, which is a JSON string. The claim’s value may also be an array of W3C Verifiable Credential objects using the JWT representation if the use case calls for multiple JWT VCs.
* vp_jwt: A claim whose value is a W3C Verifiable Presentation object using the JWT representation, which is a JSON string. The claim’s value may also be an array of W3C Verifiable Presentation objects using the JWT representation if the use case calls for multiple JWT VPs.
* vc_ld: A claim whose value is a W3C Verifiable Credential object using the JSON-LD representation, which is a JSON object. The claim’s value may also be an array of W3C Verifiable Credential objects using the JSON-LD representation if the use case calls for multiple JSON-LD VCs.
* vp_ld: A claim whose value is a W3C Verifiable Presentation object using the JSON-LD representation, which is a JSON object. The claim’s value may also be an array of W3C Verifiable Presentation objects using the JSON-LD representation if the use case calls for multiple JSON-LD VPs.
Let’s discuss this proposal during the European-friendly Connect call ~13.5 hours from now.
Openid-specs-ab mailing list
<mailto:Openid-specs-ab at lists.openid.net> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab