[Openid-specs-ab] Defining JWT Claims to represent W3C Verifiable Credentials objects
david at alkaline-solutions.com
Sat Apr 10 06:23:04 UTC 2021
> On Apr 9, 2021, at 12:00 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> Hi David,
>> 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.
> Would that be a reason to not include the JSON-LD payload in the id token (or whatever JWT comes to mind) at all?
Just to be clear, there may be different things happening with different trade-offs.
1. JWS with a payload of JSON-LD information
2. JWS with a JSON-LD -based VC / VP payload
3. JWT as defined by the VC data model spec (to have VC/VP data model encoded into a JWT)
4. JSON-LD content embedded as a claim in an id_token/userinfo response
5. VC/VP content embedded as a claim in an id_token, e.g. encoded to support both the VC and id_token rules.
(#1, #2 and #4 don’t appear to exist yet - I’m not sure if that is because JSON-LD interest is being driven entirely by the identity use case or if it is for some other reason)
I would be fine personally separating out VC/VP data from the id_token. In a way, it is somewhat surprising that there was never an inline userinfo_token for claims (I admit to not fully understanding the body of trade-offs there, though)
Embedding JSON-LD in general - there are really two issues, overlapping namespaces between the JSON-LD context and the JWT, and potentially having two different understandings of the content depending on whether the JWT payload is being evaluated as JSON or as RDF. Both of these are solved by having the data embedded in a claim, vs having the attributes and an “@context” at the root.
Embedding VC information in a JWT per VC rules has a lot of impact, partly because the security properties are both under defined and open to interpretation.
For example, that spec allows you to either use a JWS signing algorithm, or use a “proof” element in the VC with the JWT being set to alg “none”. You must also transfer or duplicate values like the credential subject @id to `sub`. However, there are a many security-impacting edge cases here, for example:
- having values which are only present in the JWT claims when you have disabled signing means they may not be covered by a signature
- removing the id from credential subject changes the interpretation of the RDF
- altering the RDF by transferring values over will affect the canonicalization, and thus the signature
- if the value exists in both places, there is no rule for processing e.g “credentialSubject.id <http://credentialsubject.id/> and `sub`, if both exist, must both be set to the same value” and “if credentialSubject.id <http://credentialsubject.id/> exists and sub was not set, the JWT is considered invalid."
>> 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 think the reason for supporting JSON-LD in this context is to allow for selective disclosure and ZKP proofs.
There are no semantics currently for a JWT to have selective disclosure semantics or to use ZKP proofs. So we can embed these in, as a JSON sub-document, a string, or base64 encoded data, to be consumed by those who can understand them.
> So what is your concrete recommendation for treating JSON-LD based VCs/VPs? Embedding as JSON, separating them by base64url encoding, separating them in separate artefacts,…?
Right now it would be for them to be separate artifacts. However I don’t know if I have the same set of use cases in mind that Mike does (in particular, he mentioned use cases where they are claims from the UserInfo Endpoint).
I haven’t seen a proposal, but I suspect we will have issues with portable identifiers in SIOP use cases. When the portable identifier verification methods do not correspond to a JOSE signature algorithm, how do you protect an id_token?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab