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

Tom Jones thomasclinganjones at gmail.com
Mon Apr 12 14:51:00 UTC 2021


What's a use case for any cred in an oidc or siop flow. It sounds like an
error condition to me.

thx ..Tom (mobile)

On Mon, Apr 12, 2021, 4:30 AM Kristina Yasuda <Kristina.Yasuda at microsoft.com>
wrote:

> The intent was to define claims that can be used both inside ID Token
> (implicit flow/SIOP), and in UserInfo response (code flow). There are
> use-cases that use VC/VPs with OpenID Connect not just in SIOP (implicit
> flow with user-controlled OP) but also with the 'conventional' code flow,
> and I believe we need a generic way that works for both.
>
> Best,
> Kristina
> ------------------------------
> *差出人:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> が Tom
> Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> の代理で送信
> *送信日時:* 2021年4月11日 0:42
> *宛先:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *CC:* Tom Jones <thomasclinganjones at gmail.com>; oliver.terbu at mesh.xyz <
> oliver.terbu at mesh.xyz>
> *件名:* Re: [Openid-specs-ab] Defining JWT Claims to represent W3C
> Verifiable Credentials objects
>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcredentialsubject.id%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C05c59674b4a8464f134108d8fc375cf9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637536662057152617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uG9Ha%2FPus0Jf46xNg8jNYv2MR6Acmv74lTWxzC1QXEg%3D&reserved=0> and
> `sub`, if both exist, must both be set to the same value” and “if
> credentialSubject.id
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcredentialsubject.id%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C05c59674b4a8464f134108d8fc375cf9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637536662057162572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FhdkSCA8HFteGrDxO9tYzcwvwAjoHt0xLG5qESSdBC8%3D&reserved=0> 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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C05c59674b4a8464f134108d8fc375cf9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637536662057162572%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HzMudfzvoHf6uCo15bJttZmUgJD%2FxJo%2BJ23K9b4UwY0%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210412/7997a37f/attachment.html>


More information about the Openid-specs-ab mailing list