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

Tom Jones thomasclinganjones at gmail.com
Thu Apr 8 04:15:26 UTC 2021 

This is not an open I'd spec. It is a very thin wrapping around VCs. That's
not what I call interoperability.

thx ..Tom (mobile)

On Wed, Apr 7, 2021, 8:55 PM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> VCs would be encoded using the rules in the VC spec - either in JWT format
> or JSON-LD format.  These encoded VCs could then be passed as parameters as
> JWT claims. I believe that people are using all four standard
> representations of Verifiable Credential objects (vp_jwt, vp_ld, vc_jwt,
> vc_ld) with JWTs (such as ID tokens) and sets of JSON claims (such as
> UserInfo Endpoint responses).  To promote interoperability, it seems
> better to have standard claims that allow people to use the representations
> they choose rather than to have everyone do the same thing slightly
> differently.
> Kristina
>
> ------------------------------
> *差出人:* nadalin at prodigy.net <nadalin at prodigy.net>
> *送信日時:* 2021年4月8日 11:06
> *宛先:* Kristina Yasuda <Kristina.Yasuda at microsoft.com>; 'Artifact
> Binding/Connect Working Group' <openid-specs-ab at lists.openid.net>
> *CC:* oliver.terbu at mesh.xyz <oliver.terbu at mesh.xyz>
> *件名:* RE: [Openid-specs-ab] Defining JWT Claims to represent W3C
> Verifiable Credentials objects
>
>
> Not quite the case as there are specific rules for encoding and decoding
> JWT in the verifiable credential specification and how to process certain
> JWT claims iss, aud, etc. So I’m still confused what you are trying to
> accomplish.
>
>
>
> *From:* Kristina Yasuda <Kristina.Yasuda at microsoft.com>
> *Sent:* Wednesday, April 7, 2021 6:53 PM
> *To:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *Cc:* Anthony Nadalin <nadalin at prodigy.net>; oliver.terbu at mesh.xyz
> *Subject:* Re: [Openid-specs-ab] Defining JWT Claims to represent W3C
> Verifiable Credentials objects
>
>
>
> VC specification defined `vp`, `vc` claims, but they are defined only to
> include "tthose parts of the standard verifiable credentials and verifiable
> presentations where no explicit encoding rules for JWT exist". Hence `vp`,
> `vc` claims are only a part of the the entire VP, VC.
>
>
>
> There is a need a define a standard way to return VPs using OpenID
> Connect, and the proposal is to use `vp_jwt`, `vp_ldp` claims that would
> include entire VP inside the ID token. (VP in a JWT format inside
> `vp_jwt` would include `vp` claim)
>
> Example can be found here: Examples for the vp_jwt, vp_ldp proposal -
> HackMD
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackmd.io%2FgrbDXDHqTE6lhu6fvVFIuA&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C56118996360b46782dff08d8fa32e797%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637534444171960134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OFBWyI5KJsmUTir%2BlqdGR4R%2Fdbtsl6UTrL460CXDj2U%3D&reserved=0>
>
>
>
> Note that this proposal is intended to work not only with SIOP V2, but
> also if VPs are to be returned from the user_info endpoint for example.
>
>
>
> Best,
>
> Kristina
> ------------------------------
>
> *差出人**:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> が
> ANTHONY NADALIN via Openid-specs-ab <openid-specs-ab at lists.openid.net>
> の代理で送信
> *送信日時**:* 2021年4月8日 10:09
> *宛先**:* Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> *CC:* Anthony Nadalin <nadalin at prodigy.net>; oliver.terbu at mesh.xyz <
> oliver.terbu at mesh.xyz>
> *件名**:* Re: [Openid-specs-ab] Defining JWT Claims to represent W3C
> Verifiable Credentials objects
>
>
>
> I  don't quite understand this proposal as if you read the verifiable
> credential specification you will see a section called JWT encoding and JWT
> decoding based upon what Mike is written I don't understand how you could
> abide by a fully compliant verifiable credential specification without
> encoding and decoding JWT's into verifiable credentials.
>
>
>
> Get Outlook for Android
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C56118996360b46782dff08d8fa32e797%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637534444171960134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6hLPo84Ac%2Fsvu2wbKuY6q3wcrXus3EpIQN2aAQmpqvI%3D&reserved=0>
>
>
> ------------------------------
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
> behalf of Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net>
> *Sent:* Wednesday, April 7, 2021 6:00:29 PM
> *To:* 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>
> *Subject:* Re: [Openid-specs-ab] Defining JWT Claims to represent W3C
> Verifiable Credentials objects
>
>
>
> I have an alternate proposal. In my system the claim should have a name
> that represents what it is. For example the existing claims acr and amr
> should be enabled to carry a vc or vp as its value. In this system the
> encoding of the value would carry the syntax of the claim, beit vc-sjon,
> vc-ld or whatever. The one proposal I did make was to use jose encoding. If
> we wanted to use this the jose header could contain the syntax of the
> contained element as Mike has indicated in his proposal.
>
>
>
> I think it is not helpful for the name of the claim to be just the syntax
> of the element.
>
>
> Be the change you want to see in the world ..tom
>
>
>
>
>
> On Wed, Apr 7, 2021 at 5:25 PM Mike Jones via Openid-specs-ab <
> 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.
>
>
>
>                                                        -- Mike
>
>
>
> _______________________________________________
> 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%7C56118996360b46782dff08d8fa32e797%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637534444171970092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ITGirOTxF1v6VQbb1UVejb%2BB2mt7JEdIMcxmVR6dMB0%3D&reserved=0>
>
> _______________________________________________
> 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/20210407/3c57e1ca/attachment.html>

More information about the Openid-specs-ab mailing list