<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
<p>Aaron, thanks for your feedback. I want to make sure we’re aligned on what the draft actually says.</p>
<p>You mention not supporting adoption because:</p><p>> <span style="color:rgb(14,14,14);font-family:".AppleSystemUIFont";font-size:14px">The problematic language is the non-normative suggestion of using an ID token as a bearer token to access resources at other domains. We should not be encouraging this behavior even if it exists in the wild.</span></p><p><span style="color:rgb(14,14,14);font-family:".AppleSystemUIFont";font-size:14px">> I do not believe the draft should be adopted as is, because of the language suggesting it is okay to use ID tokens directly across domains.</span></p>
<p>To clarify:</p>
<p><span></span></p><ul><li>
<p>Neither the word <i>resource</i> nor <i>domain</i> appears in the draft.</p>
</li><li>
<p>The draft does <span><b>not</b></span> suggest using the ID Token as a bearer token.</p></li><li><p>The draft does <span><b>not</b></span> suggest using ID Tokens across domains.</p></li></ul>
<p>If there is specific text that suggests otherwise, please point it out so we can correct it.</p><p>We will add additional non-normative text that instructs readers to not use the ID Token for access, as well as to not use the same keys for signing other objects.</p>
<p>It sounds like you agree with Karl (co-author of <i>Identity Assertion Authorization Grant</i>) that normative language around key binding is useful. I hope with the clarifications above—and with the additional non-normative guidance—we address your concerns about adoption.</p>
<p>/Dick</p></div><div dir="ltr"><span style="font-family:"Helvetica Neue";font-size:13px"><br><br></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 26, 2025 at 11:33 PM Aaron Parecki 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"><div><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">I do not support adoption of the draft as it currently stands, for similar reasons to the previous replies on this topic.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">The problematic language is the non-normative suggestion of using an ID token as a bearer token to access resources at other domains. We should not be encouraging this behavior even if it exists in the wild.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">However, I do have a use for binding a DPoP key to an ID Token. One application of the OAuth draft "Identity and Authorization Chaining Across Domains" <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/</a> involves exchanging an initial token from the domain that issued it (using RFC8693 Token Exchange) for a token that moves across domains and is later exchanged for an access token using RFC7523. This is further profiled by the draft "Identity Assertion Authorization Grant" <a href="https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/" target="_blank">https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/</a> (currently in the middle of the working group adoption call), which specifies that the initial token is an identity assertion such as an ID token.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">In this flow, the OpenID Provider issues an ID token to a client. The client uses Token Exchange to exchange the ID token back at the OpenID Provider for a new JWT. It takes the new JWT to an authorization server in a different trust domain exchanging it for an OAuth access token.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">It would be valuable to be able to bind the ID token to the client using DPoP, which is possible using the method described in this OpenID draft. This use of the ID token doesn't have the problematic attribute of being used directly in another domain.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">I believe the sorts of cross-domain uses of ID tokens mentioned in the draft would likely be better accomplished using "Identity and Authorization Chaining Across Domains", which properly scopes the tokens to each trust domain.</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">All this said, I do not believe the draft should be adopted as is, because of the language suggesting it is okay to use ID tokens directly across domains. I would not want an OIDF draft to endorse this behavior.</p></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div></div><div dir="ltr" style="color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><div dir="ltr"><p style="font-size:12pt;margin-top:0px;margin-bottom:0px"></p><p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt">Aaron Parecki</p><p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt"><br></p></div><div dir="ltr" style="font-size:12pt"><br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 26, 2025 at 1:37 PM Ralph Bragg 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><div><p><strong>This message originated outside your organization.</strong></p><br><hr><br></div><div style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt"><div dir="ltr" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt">Likewise, I do not support utilisation the id token In this way for the reasons already raised. We’ve just had issues with multiple aud values being identified as a significant source of vulnerability with PKJ so extending / modifying an id tokens aud raises too many concerns for me as a potential mitigation. I don’t believe that this token should be relied on by any actor other than the intended audience. </div></div><div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231ms-outlook-mobile-body-separator-line" dir="auto" style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt"><br></div><div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231ms-outlook-mobile-signature" style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt"><div><table cellpadding="0" cellspacing="0" style="height:64.33px;border-collapse:unset;padding:0px"><tbody><tr><td align="left" height="16.67" nowrap valign="top" style="height:16.67px;vertical-align:top;padding:0px 0px 2px;border-collapse:collapse"><table style="border-collapse:collapse"><tbody><tr><td style="padding:0px"><p style="line-height:14.67px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:11pt;font-weight:bold;color:black">Ralph Bragg</span></p></td></tr></tbody></table></td></tr><tr><td align="left" height="15.33" nowrap valign="top" style="height:15.33px;vertical-align:top;padding:0px 0px 5px;border-collapse:collapse"><table style="border-collapse:collapse"><tbody><tr><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;font-weight:bold;color:rgb(16,94,102)">Chief Technology Officer</span></p></td></tr></tbody></table></td></tr><tr><td align="left" height="15.33" valign="top" style="height:15.33px;vertical-align:top;padding:0px"><table cellpadding="0" cellspacing="0" style="height:15.33px"><tbody><tr><td align="left" height="15.33" nowrap valign="bottom" style="height:15.33px;vertical-align:bottom;padding:0px 10px 0px 0px;border-collapse:collapse"><table style="border-collapse:collapse"><tbody><tr><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black">M.</span></p></td><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black"> </span></p></td><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black">+447890130559</span></p></td></tr></tbody></table></td><td align="left" height="15.33" nowrap valign="bottom" style="height:15.33px;vertical-align:bottom;padding:0px 0px 0px 2.67px;border-collapse:collapse"><table style="border-collapse:collapse"><tbody><tr><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)">T.</span></p></td><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)"> </span></p></td><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)">+44 20 4583 6770</span></p></td></tr></tbody></table></td><td align="left" height="15.33" nowrap valign="bottom" style="height:15.33px;vertical-align:bottom;padding:0px 0px 0px 10px;border-collapse:collapse"><table style="border-collapse:collapse"><tbody><tr><td style="padding:0px"><p style="line-height:13.33px;margin:0.1pt"><a href="mailto:ralph.bragg@raidiam.com" style="color:black;text-decoration-line:none" target="_blank"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt">ralph.bragg@raidiam.com</span></a></p></td></tr></tbody></table></td></tr></tbody></table></td></tr><tr><td height="10" style="width:470px;height:10px;padding:0px"><p style="line-height:0;margin:0.1pt;padding:0px;width:470px;height:10px"></p></td></tr></tbody></table></div><div><br></div></div><hr style="display:inline-block;width:952.312px"><div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> 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 Andrii Deinega via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br><b>Sent:</b> Saturday, September 27, 2025 4:26:07 AM<br><b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br><b>Cc:</b> Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>><br><b>Subject:</b> Re: [Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification</font><div> </div></div><div><div dir="ltr"><div>I believe that any recipient of a JWT (in this case, an ID Token) should immediately reject it if it isn't the intended audience (which is indicated by the aud claim), regardless of whether cryptographic binding is present or not. This alone makes the statement below too problematic for me.</div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When an RP wants to prove to another system that it has authenticated a user, it may present the ID Token as a bearer token. However, bearer tokens are vulnerable to theft and replay attacks - if an attacker intercepts the ID Token, they can impersonate the authenticated user to downstream systems that accept a ID Token as a bearer token.</blockquote><div><br></div><div>It's difficult to imagine multiple systems (recipients) sharing the same value in the aud claim (this value must be a client_id of the RP per the Core spec). It's fair to add the aud claim may contain an array with more than one element, but it's also fair to say this practice is discouraged (1) and comes with additional complexity and concerns (2).<br><br>At the end of the day... I see a lot of value, and I see the reason why people want to have the standard around "proving to another system that it has authenticated a user," but I don't think that repurposing existing ID Tokens for it is the right way to go.... I’d suggest, and actually love to see - the use of SD JWT VCs (or other VCs) for this purpose instead.</div><div><br></div><div>I haven’t reached the point where I need to "touch" Justin’s concerns... I fully agree with him on them.<br></div><div><br></div>All the best,<div>Andrii</div></div><br><div><div dir="ltr">On Fri, Sep 26, 2025 at 9:05 AM Justin Richer 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 style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I do not support adoption of this work. The ID Token is not intended to be a conveyable artifact, and using it as such is a security layer boundary. It’s hard enough to get people to not use ID Tokens as Access Tokens today, since a lot of developers see all JWTs as equivalent, really. This work would make this problem significantly worse.<div><br></div><div> — Justin<br id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231x_m_7343970695501230547lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px"><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt">This starts a two-week call for feedback on whether to adopt the OpenID Connect OpenID Connect Key Binding specification contributed to the working group by Dick Hardt and Ethan Heilman as an OpenID Connect Working Group specification. Please reply-all by Monday, September 29, 2025 saying whether you are favor of adoption or not, also saying why.<u></u><u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt">The specification was contributed at <a href="https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ8YWyonU$" style="color:rgb(70,120,134)" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html</a>. It has been extensively discussed by the working group both on calls and on the mailing list. From my observations of the discussion as a working group chair, I believe that there is consensus that it would be useful to have a standard solving the problem addressed by this specification.<u></u><u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"> Writing as a working group chair,<u></u><u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"> -- Mike<u></u><u></u></span></div><div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div></div><span style="font-family:Helvetica;font-size:12px">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px"><span style="font-family:Helvetica;font-size:12px">Openid-specs-ab mailing list</span><br style="font-family:Helvetica;font-size:12px"><a href="mailto:Openid-specs-ab@lists.openid.net" style="color:rgb(70,120,134);font-family:Helvetica;font-size:12px" target="_blank">Openid-specs-ab@lists.openid.net</a><br style="font-family:Helvetica;font-size:12px"><a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$" style="color:rgb(70,120,134);font-family:Helvetica;font-size:12px" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div></blockquote></div><br></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="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote></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="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote></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="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a></blockquote></div></div><div dir="ltr"><span style="font-family:"Helvetica Neue";font-size:13px"><br></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 26, 2025 at 11:33 PM Aaron Parecki 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"><div>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">I do not support adoption of the draft as it currently stands, for similar reasons to the previous replies on this topic.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">The problematic language is the non-normative suggestion of using an ID token as a bearer token to access resources at other domains. We should not be encouraging this behavior even if it exists in the wild.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">However, I do have a use for binding a DPoP key to an ID Token. One application of the OAuth draft "Identity and Authorization Chaining Across Domains" <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/</a> involves exchanging an initial token from the domain that issued it (using RFC8693 Token Exchange) for a token that moves across domains and is later exchanged for an access token using RFC7523. This is further profiled by the draft "Identity Assertion Authorization Grant" <a href="https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/" target="_blank">https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/</a> (currently in the middle of the working group adoption call), which specifies that the initial token is an identity assertion such as an ID token.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">In this flow, the OpenID Provider issues an ID token to a client. The client uses Token Exchange to exchange the ID token back at the OpenID Provider for a new JWT. It takes the new JWT to an authorization server in a different trust domain exchanging it for an OAuth access token.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">It would be valuable to be able to bind the ID token to the client using DPoP, which is possible using the method described in this OpenID draft. This use of the ID token doesn't have the problematic attribute of being used directly in another domain.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">I believe the sorts of cross-domain uses of ID tokens mentioned in the draft would likely be better accomplished using "Identity and Authorization Chaining Across Domains", which properly scopes the tokens to each trust domain.</p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px"><br></p>
<p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"">All this said, I do not believe the draft should be adopted as is, because of the language suggesting it is okay to use ID tokens directly across domains.<span> I would not want an OIDF draft to endorse this behavior.</span></p></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">
<div>
<div></div>
<div dir="ltr" style="color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<div dir="ltr" style="color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p style="font-size:12pt;margin-top:0px;margin-bottom:0px"></p>
<p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt">
Aaron Parecki</p>
<p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt"><br></p>
</div>
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<br>
</div>
</div>
</div>
</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 26, 2025 at 1:37 PM Ralph Bragg 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>
<div>
<p><strong>This message originated outside your organization.</strong></p><br>
<hr><br>
</div>
<div style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt">
<div dir="ltr" style="font-family:Aptos,Aptos_MSFontService,-apple-system,Roboto,Arial,Helvetica,sans-serif;font-size:12pt">
Likewise, I do not support utilisation the id token In this way for the reasons already raised. We’ve just had issues with multiple aud values being identified as a significant source of vulnerability with PKJ so extending / modifying an id tokens aud raises
too many concerns for me as a potential mitigation. I don’t believe that this token should be relied on by any actor other than the intended audience. </div>
</div>
<div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231ms-outlook-mobile-body-separator-line" style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt" dir="auto">
<br>
</div>
<div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231ms-outlook-mobile-signature" style="font-family:Aptos,-apple-system,HelveticaNeue,sans-serif;font-size:12pt">
<div>
<table cellpadding="0" cellspacing="0" style="height:64.33px;border-collapse:unset;padding:0px">
<tbody>
<tr>
<td align="left" height="16.67" nowrap style="height:16.67px;vertical-align:top;white-space:nowrap;padding:0px 0px 2px;border-collapse:collapse" valign="top">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:14.67px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:11pt;font-weight:bold;color:black">Ralph Bragg</span></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:top;white-space:nowrap;padding:0px 0px 5px;border-collapse:collapse" valign="top">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;font-weight:bold;color:rgb(16,94,102)">Chief Technology Officer</span></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td align="left" height="15.33" style="height:15.33px;vertical-align:top;padding:0px" valign="top">
<table cellpadding="0" cellspacing="0" style="height:15.33px">
<tbody>
<tr>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 10px 0px 0px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black">M.</span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black"> </span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black">+447890130559</span></p>
</td>
</tr>
</tbody>
</table>
</td>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 0px 0px 2.67px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)">T.</span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)"> </span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:rgb(2,12,12)">+44 20 4583 6770</span></p>
</td>
</tr>
</tbody>
</table>
</td>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 0px 0px 10px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><a href="mailto:ralph.bragg@raidiam.com" style="color:black;text-decoration:none" target="_blank"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;color:black;text-decoration:none">ralph.bragg@raidiam.com</span></a></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td height="10" style="width:470px;height:10px;padding:0px">
<p style="line-height:0;margin:0.1pt;padding:0px;width:100%;height:10px"></p>
</td>
</tr>
</tbody>
</table>
</div>
<div><br>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> 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 Andrii Deinega via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Sent:</b> Saturday, September 27, 2025 4:26:07 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>I believe that any recipient of a JWT (in this case, an ID Token) should immediately reject it if it isn't the intended audience (which is indicated by the aud claim), regardless of whether cryptographic binding is present or not. This alone makes the
statement below too problematic for me.</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When an RP wants to prove to another system that it has authenticated a user, it may present the ID Token as a bearer token. However, bearer tokens are vulnerable to theft and replay attacks - if an attacker intercepts the ID Token, they can impersonate the
authenticated user to downstream systems that accept a ID Token as a bearer token.</blockquote>
<div><br>
</div>
<div>It's difficult to imagine multiple systems (recipients) sharing the same value in the aud claim (this value must be a client_id of the RP per the Core spec). It's fair to add the aud claim may contain an array with more than one element, but it's also
fair to say this practice is discouraged (1) and comes with additional complexity and concerns (2).<br>
<br>
At the end of the day... I see a lot of value, and I see the reason why people want to have the standard around "proving to another system that it has authenticated a user," but I don't think that repurposing existing ID Tokens for it is the right way to go....
I’d suggest, and actually love to see - the use of SD JWT VCs (or other VCs) for this purpose instead.</div>
<div><br>
</div>
<div>I haven’t reached the point where I need to "touch" Justin’s concerns... I fully agree with him on them.<br>
</div>
<div><br>
</div>
All the best,
<div>Andrii</div>
</div>
<br>
<div>
<div dir="ltr">On Fri, Sep 26, 2025 at 9:05 AM Justin Richer 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 style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>I do not support adoption of this work. The ID Token is not intended to be a conveyable artifact, and using it as such is a security layer boundary. It’s hard enough to get people to not use ID Tokens as Access Tokens today, since a lot of developers see
all JWTs as equivalent, really. This work would make this problem significantly worse.
<div><br>
</div>
<div> — Justin<br id="m_8704886426434873647m_-602771694513808945m_8683371601221626491m_2509302665896969231x_m_7343970695501230547lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div>
<br>
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt">This starts a two-week call for feedback on whether to adopt the OpenID Connect OpenID Connect Key Binding specification contributed to the working group by Dick
Hardt and Ethan Heilman as an OpenID Connect Working Group specification. Please reply-all by Monday, September 29, 2025 saying whether you are favor of adoption or not, also saying why.<u></u><u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt">The specification was contributed at<span> </span><a href="https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ8YWyonU$" style="color:rgb(70,120,134);text-decoration:underline" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html</a>.
It has been extensively discussed by the working group both on calls and on the mailing list. From my observations of the discussion as a working group chair, I believe that there is consensus that it would be useful to have a standard solving the problem
addressed by this specification.<u></u><u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"> Writing as a working group chair,<u></u><u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"> -- Mike<u></u><u></u></span></div>
<div style="margin:0in;font-size:12pt;font-family:Aptos,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div>
</div>
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Openid-specs-ab
mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<a href="mailto:Openid-specs-ab@lists.openid.net" style="color:rgb(70,120,134);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Openid-specs-ab@lists.openid.net</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$" style="color:rgb(70,120,134);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div>
</blockquote>
</div>
<br>
</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="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</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="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></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="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div></div></div></div></div></div></div></div></div></div>
</div></div></div></div>
</div>