[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 23:06:15 UTC 2021


Hi

On Thu, May 13, 2021 at 2:13 AM Jeremie Miller <jmiller at pingidentity.com>
wrote:

> The current draft of Claims Aggregation asserts very specific rules around
> how claims are cryptographically bound throughout their lifecycle, and
> those (noted below) are currently incompatible with a privacy-preserving
> presentation using proofs.
>

Please see issue #1219 etc. Current draft is almost assuming SIOP but it is
to be generalized to accommodate a regular OP as well as DID/VC.
It is on its way.


> These can definitely be addressed and the draft improved, which IMO would
> look like some blend of the Claims Aggregation draft, the OIDC4VCO draft,
> and the Credential Provider draft.  A decision likely needs to be agreed
> upon whether the issuance and presentation can usefully exist as separate
> specs or not.
>

It was previously agreed that much of the Credential Provider draft where
it makes sense will be merged into the Claims Aggregation draft.


>
> Jer
> ----
>
> Note - some of the items of concern (based on my understanding) are:
> * The "uid" value is required and correlatable
>

`uid` value is supposed to be PPID or Ephemeral Identifier. It is required
to achieve uncorrelability/unlinkability among RP (by PPID) and even
within an RP (by ephemeral identifier), i.e., Anonymous Attribute
Authentication.
NOTE: the current definition of `uid` is specific to SIOP. This has been
previously discussed and agreed to generalize it to allow the case for a
regular OP and DID.

* The audience requirements are not practical (final/eventual audience is
> unknown when claims are issued)
>

That's why it is put "???" there. At the same time, having an audience
would guard against replay and forwarding (which is a threat to privacy)
and helps RP's privacy compliance programme.


> * It requires JWTs for signed/encrypted aggregated results
>

See my previous message.


> * It suggests no or long expiration, which requires providers and
> verifiers to implement revocation (which is a very complicated subject)
>

The principle of OIDC is to have a short expiration token. It is almost
assumed. That's why OIDC does not generally have a revocation thing.
 You can raise an issue against the draft and make a PR.


> All these can be iteratively improved, the result is likely to look
> notably different than the current draft.  I'm happy to start filing issues
> if or when that would be helpful.
>

That's what I have been asking for the last half a year. That's the correct
process.
I have grown a bit impatient and started filing myself although I have been
kind of avoiding it as I am a co-chair.


>
> On Wed, May 12, 2021 at 7:59 AM Nat Sakimura via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> 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
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*



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


More information about the Openid-specs-ab mailing list