[Openid-specs-ab] Defining JWT Claims to represent W3C Verifiable Credentials objects

Tom Jones thomasclinganjones at gmail.com
Sat Apr 10 15:42:49 UTC 2021


Lot's of this thread has veered off into the hypothetical. I guess I need
to understand from Mike if his proposal for vx.yz claims applies only to
SIOP, which (for example) has no need for a user info endpoint, or more
generally.  If we can just include the needs of siop in the siop doc, there
will be less of this hypothetical to deal with.

Be the change you want to see in the world ..tom


On Fri, Apr 9, 2021 at 11:23 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

>
>
> 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 and `sub`, if both exist, must both be set to the
> same value” and “if 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?
>
> -DW
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210410/d52bc4ff/attachment.html>


More information about the Openid-specs-ab mailing list