[Openid-specs-ab] Relationship with Claims Aggregation Draft (was Re: Issue #1229: Adoption of the "OpenID Connect for W3C Verifiable Credential Objects" (openid/connect))

Nat Sakimura nat at nat.consulting
Wed May 12 13:58:29 UTC 2021


Dear Kristina,

Claims Aggregation draft deals with the following:

* an intermediate OP (client) to perform discovery for a Claims Provider
Metadata;
* an intermediate OP to register as a client to a Claims Provider;
* an intermediate OP to obtain claims from the Claims Provider;
* an RP to ask for verified claims to the intermediate OP; and
* an intermediate OP returned aggregated claims from Claims Providers to
requesting clients.

In the last bullet point, "aggregated claims" means the claims that were
gathered from claim providers/sources.
They are returned in the "_claim_sources" member.
e.g.

   "_claim_sources": {
     "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
   }

Unlike your statement "Claims Aggregation draft covers very specific
response syntax", it is just a generic OIDC Core response format.

These claims may be obtained from CPs previously. It does not have to be
real-time at all.
It is semantically equivalent to providing Verifiable Presentation using
stored Verified Claims that were held by the "wallet" software.

Note 1: "an intermediate OP" is equivalent to the "wallet" software.
Note 2: It is a software process that presents and not the user.

I cannot speak for Tony or Tobias, but my understanding of their comment is
that by adding another response format like "vp_ldp", "vp_jwt" in addition
to "JWT" stated in the OIDC core and is explained in the Claims Aggregation
draft (or as a sub-type under "JWT"), it seems the presentation issue can
be dealt with. (I kind of remember Tony talking about it a long time ago
especially in the context of mDL and the above "guess" is informed by the
experience.)

e.g.

   "_claim_sources": {
     "src1": {"vp_jwt": "jwt_header.jwt_part2.jwt_part3"}
   }


I am guessing this is why Tony wrote: "at the top level there is a 100%
overlap on transporting the claims, as this is what a presentation does".

Am I correct? > Tony?

Are you ok with a new draft being written for VP Token as described in
Section 7 of the OIDC4VDO draft as long as the above portion is merged into
the Claims Aggregation draft? > Tony.

Let us know.

Best,

Nat Sakimura

On Wed, May 12, 2021 at 12:22 PM Kristina Yasuda <
Kristina.Yasuda at microsoft.com> wrote:

> I think we need more careful analysis when talking about merging Claims
> Aggregation and OpenID Connect for Verifiable Presentations drafts. I'm
> still finding the right words to articulate it, so please bear with me.
>
> Yes, they both transport the claims, but as was discussed during the
> call, presenting a proof that you have a set of claims is different from
> presenting the claims themselves. Credential Isuance and Credential
> Presentation is different. Especially so in W3C Verifiable Credentials
> Objects world. Claims Provider presents the end-user with a verifiable
> credential, signed by the Claims Provider. Than the end-user presents a
> verifiable presentation to the Relying Party, which is the end-user's proof
> of possession of verifiable credential. and these two "presentations" do
> not have to occur consequentially.
>
> Claims Aggregation is different in that it involves the Claims Provider as
> an additional entity. As an "intermediate OP", you do not want contacting
> Claims Provider everytime you present the claims/posession of the claims
> once you have received claims bound to the requesting client (potentially
> from several Claims Providers).
>
> As the name suggests, Claims Aggregation draft covers very specific
> response syntax - aggregated claims. It could be used when initially
> receiving the claims from the Claims Provider, but so far it has been voted
> out to use it when presenting the claims/posession of the claims between
> to the Relying Party, in OpenID Connect for Verifiable Presentations
> draft discussion  - of course we can, and probably shoud, reconsider it,
> but worth pointing out.
>
> Both drafts may use same building blocks (Authentication Requests and
> Responses), because those are fundametal to OpenId Connect, and it would be
> ideal to have the same flow for an issuance from "Claims Provider" and a
> presentation from "OpenID Provider", but there are several nuances why
> these two should be aligned but not entirely merged.
>
> Kindest Regards,
> Kristina
>
> ------------------------------
> *差出人:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> が
> nadalin--- via Openid-specs-ab <openid-specs-ab at lists.openid.net> の代理で送信
> *送信日時:* 2021年5月12日 11:21
> *宛先:* 'Artifact Binding/Connect Working Group' <
> openid-specs-ab at lists.openid.net>; nat <nat at nat.consulting>
> *CC:* Anthony Nadalin <nadalin at prodigy.net>; 'Nat' <
> issues-reply at bitbucket.org>
> *件名:* Re: [Openid-specs-ab] Relationship with Claims Aggregation Draft
> (was Re: Issue #1229: Adoption of the "OpenID Connect for W3C Verifiable
> Credential Objects" (openid/connect))
>
> I think at the top level there is a 100% overlap on transporting the
> claims, as this is what a presentation does
>
> -----Original Message-----
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On
> Behalf Of Torsten Lodderstedt via Openid-specs-ab
> Sent: Tuesday, May 11, 2021 8:22 AM
> To: Nat Sakimura <nat at nat.consulting>
> Cc: Torsten Lodderstedt <torsten at lodderstedt.net>; Nat <
> issues-reply at bitbucket.org>; Artifact Binding/Connect Working Group <
> openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] Relationship with Claims Aggregation Draft
> (was Re: Issue #1229: Adoption of the "OpenID Connect for W3C Verifiable
> Credential Objects" (openid/connect))
>
>
>
> > Am 11.05.2021 um 16:11 schrieb Nat Sakimura via Openid-specs-ab <
> openid-specs-ab at lists.openid.net>:
> >
> > I am writing this to record what I and some WG members explained during
> the Monday call.
> >
> > With regards to the Relationship with Claims Aggregation draft, what is
> stated below is not correct. The Claims Aggregation Draft actually talks
> about Authentication Requests and Responses in addition to the registration
> of the intermediate OP to the claims provider.
> >
> > If I understand correctly, Tobias has been looking into how to expand
> what is being written currently so that it can also express the VC and ZKP.
> >
> > I would like to ask the proposers to clarify this as a lot of this draft
> could potentially be merged into the Claims Aggregation draft as suggested
> by Tony etc.
>
> What do you think in the current proposal for Verifiable Credential
> Presentation overlaps with Claims Aggregation?
>
> I guess Tobias referred to the merging of the Credential Issuer Draft
> (different draft by Tobias and Adam
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmattrglobal.github.io%2Foidc-client-bound-assertions-spec%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KNIlUPEouhNWpP%2FBkQzpxTHlSGEd7NmYj4SKbEVhJyg%3D&reserved=0)
> with Claims Aggregation.
>
> >
> > Best,
> >
> > Nat Sakimura
> >
> > On Mon, May 10, 2021 at 9:39 PM Kristina Yasuda via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> > Thank you, Nat.
> >
> > As promised, I wanted to outline the relationship between "OpenID
> > Connect for W3C Verifiable Credential Objects" (OIDC4VCO) draft and
> other existing drafts. (point 2 in this issue) ※ Note that there was a
> proposal to rename the draft  "OpenID Connect for W3C Verifiable
> Presentations", but I will use OIDC4VCO abbreviation for now.
> >
> >        • Relationship with OpenID Connect Core: OIDC4VCO uses mechanisms
> already defined in OIDC Core, and does not introduce any breaking changes.
> >        • Relationship with SIOP V2 draft: SIOP V2 draft will refer to
> the OIDC4VCO draft wrt how W3C verifiable presentations (VPs) can be
> transported using SIOP model, since OIDC4VCO draft defines a generic way
> how W3C VPs can be used with various OIDC flows including SIOP V2.
> >        • Relationship with Claims Aggregation draft (and Credential
> Provider draft once contributed): these drafts will be used by the OP to
> receive credentials from the Claims Provider, so that the OP will be able
> to present received credentials to the RP using OIDC4VCO draft. These
> drafts should be aligned as much as possible.
> >        • Relationship with DIF Presentation Exchange (PE) draft: DIF PE
> draft could be used as part of the request syntax in OIDC4VCO draf, which
> can be discussed once OIDC4VCO draft is adopted. DIF PE is a query language
> that is protocol agnostic, and it does not replace OIDC4VCO draft.
> > This is an initial summary and additional input from the editors/working
> group is very welcome.
> >
> > A work item to enable transporting W3C VPs using OpenID Connect, will
> most likely not be successful outside OpenID Foundation AB/C Working Group,
> because that is where the collective OpenID Connect expertise resides.
> >
> > Best,
> > Kristina
> >
> >
> > 差出人: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> が Nat
> > via Openid-specs-ab <openid-specs-ab at lists.openid.net> の代理で送信
> > 送信日時: 2021年5月7日 0:55
> > 宛先: openid-specs-ab at lists.openid.net
> > <openid-specs-ab at lists.openid.net>
> > CC: Nat <issues-reply at bitbucket.org>
> > 件名: [Openid-specs-ab] Issue #1229: Adoption of the "OpenID Connect for
> > W3C Verifiable Credential Objects" (openid/connect)
> >
> > New issue 1229: Adoption of the "OpenID Connect for W3C Verifiable
> Credential Objects"
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitb
> > ucket.org%2Fopenid%2Fconnect%2Fissues%2F1229%2Fadoption-of-the-openid-
> > connect-for-w3c&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C5
> > 46f6f574aa946624ea408d910a766d3%7C72f988bf86f141af91ab2d7cd011db47%7C1
> > %7C0%7C637559134036105710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v8JUcU
> > VcU4A%2FlkpyB43J2%2B9DB9axNOyOGjmQAe5GU58%3D&reserved=0
> >
> > Nat Sakimura:
> >
> > SIOP SC recommended the adoption of “[OpenID Connect for W3C Verifiable
> Credential Objects](
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F20210505%2Fa198527a%2Fattachment-0001.pdf&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K5XR%2FIjX22nd1f6W6%2FHJs21N8oyet3od6TnIprq0G2E%3D&reserved=0)”
> \[1\] as a working group item.
> >
> > \[1\]
> > [https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> > s.openid.net%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F20210505%2F
> > a198527a%2Fattachment-0001.pdf&data=04%7C01%7CKristina.Yasuda%40mi
> > crosoft.com%7C546f6f574aa946624ea408d910a766d3%7C72f988bf86f141af91ab2
> > d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown%7CTWFpbGZsb3d8eyJWI
> > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> > mp;sdata=38hwxalY%2FRk1ypItq%2Bnxnhd26OE4uUJ79XUm1T8DVNw%3D&reserv
> > ed=0](https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2
> > Flists.openid.net%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F202105
> > 05%2Fa198527a%2Fattachment-0001.pdf&data=04%7C01%7CKristina.Yasuda
> > %40microsoft.com%7C546f6f574aa946624ea408d910a766d3%7C72f988bf86f141af
> > 91ab2d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown%7CTWFpbGZsb3d8
> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> > 000&sdata=38hwxalY%2FRk1ypItq%2Bnxnhd26OE4uUJ79XUm1T8DVNw%3D&r
> > eserved=0)
> >
> > Some concerns were expressed by a few WG members.
> >
> > This ticket is to give an opportunity for those members to express their
> concerns and proposers to reply to them.
> >
> > There are a few criteria for non-adoption of documents: namely
> >
> > 1. If the draft does not fall into the scope of the WG.
> > 2. If the draft is overlapping with existing drafts, the technical
> content should be raised as an issue and eventually result in PR rather
> than starting a new draft.
> >
> >     1. NOTE: A non-overlapping portion can be made as an independent
> document so proposers should consider creating such.
> >
> > 3. If there is a legal or reputational risk for the OIDF in adopting
> > the document. \(The board may intervene on this ground.\)
> >
> > If the issues are only on the technical nature of the proposed draft
> that does not fall into the above criteria, then, it should be dealt with
> during and after the adoption of the document.
> >
> > ‌
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7C
> > Kristina.Yasuda%40microsoft.com%7C546f6f574aa946624ea408d910a766d3%7C7
> > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown
> > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > XVCI6Mn0%3D%7C1000&sdata=zj60E0N480Cv0Pqtne%2FbRk%2FOu8%2BJ8toFtZ6
> > kNncNnHY%3D&reserved=0
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> >
> 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%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZUpNdezJeV78SAZtTfz7CSSfiWMxAW%2BFudA%2BJrgzw8s%3D&reserved=0
> >
> >
> > --
> > Nat Sakimura
> > NAT.Consulting LLC
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttp%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2F&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ajLTQWBZF%2FcWheTofVYKMI7w4XhBAk9%2BtW3xbDDSrag%3D&reserved=0
> > openid-specs-ab&source=gmail-imap&ust=1621347127000000&usg=AOvVaw3Bh-F
> > RqnYOtpjBVhuUTQkW
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
>
> 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%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&reserved=0
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
>
> 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%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&reserved=0
>


-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210512/40ad923c/attachment-0001.html>


More information about the Openid-specs-ab mailing list