<div dir="ltr"><div dir="ltr"><br></div>Hi<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 2:13 AM Jeremie Miller <<a href="mailto:jmiller@pingidentity.com">jmiller@pingidentity.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>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. </div><div>It is on its way. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>It was previously agreed that much of the Credential Provider draft where it makes sense will be merged into the Claims Aggregation draft. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div><div>Jer</div><div>----</div><div><br></div><div>Note - some of the items of concern (based on my understanding) are:</div><div>* The "uid" value is required and correlatable</div></div></div></div></blockquote><div><br></div><div>`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. </div><div>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.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>* The audience requirements are not practical (final/eventual audience is unknown when claims are issued)</div></div></div></div></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>* It requires JWTs for signed/encrypted aggregated results</div></div></div></div></blockquote><div><br></div><div>See my previous message. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>* It suggests no or long expiration, which requires providers and verifiers to implement revocation (which is a very complicated subject)</div></div></div></div></blockquote><div><br></div><div>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. </div><div> You can raise an issue against the draft and make a PR. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><br></div></div></div><div>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.</div></div></blockquote><div><br></div><div>That's what I have been asking for the last half a year. That's the correct process. </div><div>I have grown a bit impatient and started filing myself although I have been kind of avoiding it as I am a co-chair. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 7:59 AM Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Kristina, <div><br></div><div>Claims Aggregation draft deals with the following: </div><div><br></div><div>* an intermediate OP (client) to perform discovery for a Claims Provider Metadata;<br>* an intermediate OP to register as a client to a Claims Provider;<br>* an intermediate OP to obtain claims from the Claims Provider;<br>* an RP to ask for verified claims to the intermediate OP; and<br>* an intermediate OP returned aggregated claims from Claims Providers to requesting clients.<br></div><div><br></div><div>In the last bullet point, "aggregated claims" means the claims that were gathered from claim providers/sources. </div><div>They are returned in the "_claim_sources" member. </div><div>e.g. </div><div><pre style="font-family:"Courier New",Courier,monospace;padding:4px;color:rgb(0,0,0);background-color:rgb(204,204,204)">   "_claim_sources": {
     "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}
   }</pre></div><div>Unlike your statement "Claims Aggregation draft covers very specific response syntax", it is just a generic OIDC Core response format. <br></div><div><br></div><div>These claims may be obtained from CPs previously. It does not have to be real-time at all.</div><div>It is semantically equivalent to providing Verifiable Presentation using stored Verified Claims that were held by the "wallet" software. </div><div><br></div><div>Note 1: "an intermediate OP" is equivalent to the "wallet" software. </div><div>Note 2: It is a software process that presents and not the user. </div><div><br></div><div>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.) </div><div><br></div><div><div>e.g. </div><div><pre style="font-family:"Courier New",Courier,monospace;padding:4px;color:rgb(0,0,0);background-color:rgb(204,204,204)">   "_claim_sources": {
     "src1": {"vp_jwt": "jwt_header.jwt_part2.jwt_part3"}
   }</pre></div><div></div></div><div><br></div><div>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". </div><div><br></div><div>Am I correct? > Tony? </div><div><br></div><div>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. </div><div><br></div><div>Let us know. </div><div><br></div><div>Best, </div><div><br></div><div>Nat Sakimura</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 12:22 PM Kristina Yasuda <<a href="mailto:Kristina.Yasuda@microsoft.com" target="_blank">Kristina.Yasuda@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Yes, they both transport the claims, but a<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">s 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.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"><span style="background-color:rgb(255,255,255);display:inline">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). </span><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"> </span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">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/<span style="background-color:rgb(255,255,255);display:inline">posession of the claims<span> between to the Relying Party, </span></span>in </span><span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">OpenID
 Connect for Verifiable Presentations draft discussion  - of course we can, and probably shoud, reconsider it, but worth pointing out.</span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">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.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">Kindest Regards,</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">Kristina</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"><br>
</span></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_8208339931028886302gmail-m_-1457572443669427904gmail-m_-7646193988652629391divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>差出人:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> が nadalin--- via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> の代理で送信<br>
<b>送信日時:</b> 2021年5月12日 11:21<br>
<b>宛先:</b> 'Artifact Binding/Connect Working Group' <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>; nat <nat@nat.consulting><br>
<b>CC:</b> Anthony Nadalin <<a href="mailto:nadalin@prodigy.net" target="_blank">nadalin@prodigy.net</a>>; 'Nat' <<a href="mailto:issues-reply@bitbucket.org" target="_blank">issues-reply@bitbucket.org</a>><br>
<b>件名:</b> 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))</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>I think at the top level there is a 100% overlap on transporting the claims, as this is what a presentation does
<br>
<br>
-----Original Message-----<br>
From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> On Behalf Of Torsten Lodderstedt via Openid-specs-ab<br>
Sent: Tuesday, May 11, 2021 8:22 AM<br>
To: Nat Sakimura <nat@nat.consulting><br>
Cc: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>>; Nat <<a href="mailto:issues-reply@bitbucket.org" target="_blank">issues-reply@bitbucket.org</a>>; Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
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))<br>
<br>
<br>
<br>
> Am 11.05.2021 um 16:11 schrieb Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>:<br>
> <br>
> I am writing this to record what I and some WG members explained during the Monday call.<br>
> <br>
> 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. <br>
> <br>
> 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.
<br>
> <br>
> 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.
<br>
<br>
What do you think in the current proposal for Verifiable Credential Presentation overlaps with Claims Aggregation?
<br>
<br>
I guess Tobias referred to the merging of the Credential Issuer Draft (different draft by Tobias and Adam
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmattrglobal.github.io%2Foidc-client-bound-assertions-spec%2F&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=KNIlUPEouhNWpP%2FBkQzpxTHlSGEd7NmYj4SKbEVhJyg%3D&amp;reserved=0" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmattrglobal.github.io%2Foidc-client-bound-assertions-spec%2F&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=KNIlUPEouhNWpP%2FBkQzpxTHlSGEd7NmYj4SKbEVhJyg%3D&amp;reserved=0</a>)
 with Claims Aggregation. <br>
<br>
> <br>
> Best,<br>
> <br>
> Nat Sakimura<br>
> <br>
> On Mon, May 10, 2021 at 9:39 PM Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> Thank you, Nat.<br>
> <br>
> As promised, I wanted to outline the relationship between "OpenID <br>
> 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.<br>
> <br>
>        • Relationship with OpenID Connect Core: OIDC4VCO uses mechanisms already defined in OIDC Core, and does not introduce any breaking changes.<br>
>        • 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.<br>
>        • 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.<br>
>        • 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.<br>
> This is an initial summary and additional input from the editors/working group is very welcome.<br>
> <br>
> 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.
<br>
> <br>
> Best,<br>
> Kristina<br>
> <br>
> <br>
> 差出人: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> が Nat <br>
> via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> の代理で送信<br>
> 送信日時: 2021年5月7日 0:55<br>
> 宛先: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> <br>
> <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
> CC: Nat <<a href="mailto:issues-reply@bitbucket.org" target="_blank">issues-reply@bitbucket.org</a>><br>
> 件名: [Openid-specs-ab] Issue #1229: Adoption of the "OpenID Connect for <br>
> W3C Verifiable Credential Objects" (openid/connect)<br>
>  <br>
> New issue 1229: Adoption of the "OpenID Connect for W3C Verifiable Credential Objects"<br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitb" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitb</a><br>
> <a href="http://ucket.org" target="_blank">ucket.org</a>%2Fopenid%2Fconnect%2Fissues%2F1229%2Fadoption-of-the-openid-<br>
> connect-for-w3c&amp;data=04%7C01%7CKristina.Yasuda%<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7C5<br>
> 46f6f574aa946624ea408d910a766d3%7C72f988bf86f141af91ab2d7cd011db47%7C1<br>
> %7C0%7C637559134036105710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi<br>
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=v8JUcU<br>
> VcU4A%2FlkpyB43J2%2B9DB9axNOyOGjmQAe5GU58%3D&amp;reserved=0<br>
> <br>
> Nat Sakimura:<br>
> <br>
> SIOP SC recommended the adoption of “[OpenID Connect for W3C Verifiable Credential Objects](<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F20210505%2Fa198527a%2Fattachment-0001.pdf&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=K5XR%2FIjX22nd1f6W6%2FHJs21N8oyet3od6TnIprq0G2E%3D&amp;reserved=0" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F20210505%2Fa198527a%2Fattachment-0001.pdf&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=K5XR%2FIjX22nd1f6W6%2FHJs21N8oyet3od6TnIprq0G2E%3D&amp;reserved=0</a>)”
 \[1\] as a working group item. <br>
> <br>
> \[1\] <br>
> [<a></a><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist</a><br>
> <a href="http://s.openid.net" target="_blank">s.openid.net</a>%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F20210505%2F<br>
> a198527a%2Fattachment-0001.pdf&amp;data=04%7C01%7CKristina.Yasuda%40mi<br>
> <a href="http://crosoft.com" target="_blank">crosoft.com</a>%7C546f6f574aa946624ea408d910a766d3%7C72f988bf86f141af91ab2<br>
> d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown%7CTWFpbGZsb3d8eyJWI<br>
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a<br>
> mp;sdata=38hwxalY%2FRk1ypItq%2Bnxnhd26OE4uUJ79XUm1T8DVNw%3D&amp;reserv<br>
> ed=0](<a></a><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2</a><br>
> <a href="http://Flists.openid.net" target="_blank">Flists.openid.net</a>%2Fpipermail%2Fopenid-specs-ab%2Fattachments%2F202105<br>
> 05%2Fa198527a%2Fattachment-0001.pdf&amp;data=04%7C01%7CKristina.Yasuda<br>
> %<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7C546f6f574aa946624ea408d910a766d3%7C72f988bf86f141af<br>
> 91ab2d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown%7CTWFpbGZsb3d8<br>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1<br>
> 000&amp;sdata=38hwxalY%2FRk1ypItq%2Bnxnhd26OE4uUJ79XUm1T8DVNw%3D&amp;r<br>
> eserved=0)<br>
> <br>
> Some concerns were expressed by a few WG members. <br>
> <br>
> This ticket is to give an opportunity for those members to express their concerns and proposers to reply to them.
<br>
> <br>
> There are a few criteria for non-adoption of documents: namely<br>
> <br>
> 1. If the draft does not fall into the scope of the WG. <br>
> 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.
<br>
> <br>
>     1. NOTE: A non-overlapping portion can be made as an independent document so proposers should consider creating such.
<br>
>     <br>
> 3. If there is a legal or reputational risk for the OIDF in adopting <br>
> the document. \(The board may intervene on this ground.\)<br>
> <br>
> 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.
<br>
> <br>
> ‌<br>
> <br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists</a><br>
> .<a href="http://openid.net" target="_blank">openid.net</a>%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7C<br>
> Kristina.Yasuda%<a href="http://40microsoft.com" target="_blank">40microsoft.com</a>%7C546f6f574aa946624ea408d910a766d3%7C7<br>
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637559134036115666%7CUnknown<br>
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ<br>
> XVCI6Mn0%3D%7C1000&amp;sdata=zj60E0N480Cv0Pqtne%2FbRk%2FOu8%2BJ8toFtZ6<br>
> kNncNnHY%3D&amp;reserved=0 <br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZUpNdezJeV78SAZtTfz7CSSfiWMxAW%2BFudA%2BJrgzw8s%3D&amp;reserved=0" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371343410%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZUpNdezJeV78SAZtTfz7CSSfiWMxAW%2BFudA%2BJrgzw8s%3D&amp;reserved=0</a><br>
> <br>
> <br>
> --<br>
> Nat Sakimura<br>
> NAT.Consulting LLC<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttp%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2F&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ajLTQWBZF%2FcWheTofVYKMI7w4XhBAk9%2BtW3xbDDSrag%3D&amp;reserved=0" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttp%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2F&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ajLTQWBZF%2FcWheTofVYKMI7w4XhBAk9%2BtW3xbDDSrag%3D&amp;reserved=0</a><br>
> openid-specs-ab&source=gmail-imap&ust=1621347127000000&usg=AOvVaw3Bh-F<br>
> RqnYOtpjBVhuUTQkW<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&amp;reserved=0" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&amp;reserved=0</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&amp;reserved=0" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C295c330fc28d4930369908d914eca5be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563829371353377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Iip8EGxUlsmkBOHfddG%2Bcu70JO9UIrQTGWVbP8VLe5k%3D&amp;reserved=0</a><br>
</div>
</span></font></div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Nat Sakimura<div>NAT.Consulting LLC</div></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Nat Sakimura<div>NAT.Consulting LLC</div></div></div></div></div>