<div dir="ltr">Thanks Dick, the changes look great.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 29 Aug 2025 at 15:48, Frederik Krogsdal Jacobsen <<a href="mailto:frederik.krogsdal@criipto.com">frederik.krogsdal@criipto.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">I think the recent changes fix this issue. I agree with Jacob that it is sometimes necessary to over-explain to avoid wrong assumptions from implementers.<div>I would suggest adding an explanation similar to what Filip wrote above to an "Implementation Considerations" section.</div><div>Perhaps something like:</div><div>"Some OpenID Providers may choose not to include the <font face="monospace">dpop</font> scope in the list of <font face="monospace">supported_scopes</font><font face="arial, sans-serif"> of </font>their OpenID Connect Metadata Document. When using such an OpenID Provider, Relying Parties SHOULD NOT add the <font face="monospace">dpop</font> scope to requests unless they can gracefully handle that the <font face="monospace">cnf</font> claim is not present in the returned ID token."</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Aug 2025 at 14:09, Dick Hardt 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 dir="ltr"><div dir="ltr"><div dir="ltr">Changes made:<br><br>- aligned `dpop` being unknown by OP with OpenID Connect specifications<div>- added metadata SHOULD for `dpop` scope and `dpop_signing_alg_values_supported`</div><div>- added some c_hash changes that were missed earlier</div><div>- added Acknowledgements</div><div>- fixed references<br><br><a href="https://github.com/dickhardt/openid-key-binding" target="_blank">https://github.com/dickhardt/openid-key-binding</a><br><br><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 29, 2025 at 8:06 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.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="auto">Works for me. Thanks for noticing the discrepancy and the discussion. As we had no call yesterday for adoption I’ll make those changes to the proposal. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 29, 2025 at 7:51 AM Jacob Ideskog <<a href="mailto:jacob.ideskog@curity.io" target="_blank">jacob.ideskog@curity.io</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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I had not noticed the discrepancy between  OAuth and OIDC on the treatment of unroecognized scopes</blockquote><div><br></div><div>It's small but important, and in this case my point was simply that a new behaviour that contradicts existing OPs could cause client's to incorrectly assume that things worked. </div><div>I think Filip's suggestion about the discovery is a better approach, this cannot be discovered by OP behaviour in the transaction since the OPs that don't support this already have a set behaviour. So the client needs to have a more active role in understanding if this works or not.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div>> One reason I like the OP returning an error 
is that it could be client specific -- IE the OP might not support the 
scope for all clients. </div><div>That is an 
excellent example in which the AS would indicate support in discovery 
but would return the invalid_scope to clients for which it doesn't 
support it. Or, again - just ignored it and the client would be required
 to stop the operation.</div></span></blockquote></div><div><br></div><div>Adding discovery support and perhaps changing the MUST to SHOULD with a comment that a client cannot expect invalid scope as a signal to if binding worked or not could be a solution. However, the risk is still that we still get developers coding this with incorrect assumptions on the protocol behaviour.</div><div><br></div><div>Additionally, compare to the PKCE spec (RFC7636) section 5, where a similar pattern is needed (but not with scope) the AS in that case ignores the code_challenge if it doesn't understand it (as per 6749), leaving the client to figure out if PKCE was actually used or not.</div></div><div dir="ltr"><div><br></div><div>/Jacob</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Aug 2025 at 17:28, Dick Hardt 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">Thanks for the clarification. <br><br>Note we are talking about an OP -- not an AS <br><br>I had not noticed the discrepancy between  OAuth and OIDC on the treatment of unroecognized scopes. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 28, 2025 at 4:11 PM Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.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>I am not suggesting either. I am simply reflecting on the existing deployed AS behaviours and how adding requirements to a new extension that contradict said behaviours is not beneficial to the requirement's purpose.</div><div><br></div><div>I'm saying that if you want a client to be sure the mechanism is supported then your only choice is a MUST for the AS to support discovery and make it a MUST to include "dpop" in the discovery responses' scopes_supported. Alternatively just have a client that needs binding and doesn't get one (AS ignored the scope) not proceed with the operation.</div><div><br></div><div>> One reason I like the OP returning an error is that it could be client specific -- IE the OP might not support the scope for all clients. </div><div><br></div><div>That is an excellent example in which the AS would indicate support in discovery but would return the invalid_scope to clients for which it doesn't support it. Or, again - just ignored it and the client would be required to stop the operation.</div><div><br></div><div><div dir="ltr" class="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Aug 2025 at 17:02, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.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">Filip: Are you suggesting that the OP should ignore the scope if not supported, or should return an error?<br><br>From your comment are you suggesting that the OP MUST or SHOULD support discovery of the scopes supported?<br><br>One reason I like the OP returning an error is that it could be client specific -- IE the OP might not support the scope for all clients. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 28, 2025 at 3:10 PM Filip Skokan <<a href="mailto:panva.ip@gmail.com" target="_blank">panva.ip@gmail.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>Especially because it's new functionality you can't rely on behaviours that existing server software isn't required to exhibit for detecting lack of support. It's okay to require discovery that informs the client that a feature is supported.</div><div><br></div><div><div dir="ltr" class="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Aug 2025 at 16:05, Dick Hardt 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">I have no strong opinion on how this should work in the key binding document.<br><br>Given it is new functionality and the RP is including the scope because it needs the key binding, it seems a better experience to fail on the request rather than for the client to learn it is not supported when it does not get back a cnf claim in the id_token. <br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 28, 2025 at 2:31 PM Renato Athaydes 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>> What is the point of this requirement?</div><div><br></div><div>Imagine being completely unable to delete a scope because that would break every OAuth client, knowing that many cannot be easily updated for a long time (their update cycle is outside of your control).</div><div><br></div><div>When you could just let the server "ignore" unknown scopes, and the client would continue working happily with only the valid scopes it requested.</div><div><br></div><div>Regards,</div><div><br></div><div>Renato Athaydes</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 28, 2025 at 2:57 PM Filip Skokan 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>There is in fact no mandate to throw on unsupported or unrecognized scopes values, the code is defined but not mandated to be used by implementers. In fact OIDC Core 1.0 explicitly says the following in <a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest" target="_blank">3.1.2.1.  Authentication Request</a> (as Jacob already pointed out).</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">Scope values used that are not understood by an implementation SHOULD be ignored.</blockquote><div><br></div><div>What is the point of this requirement? Can you instead mandate that when this specification is supported servers MUST include the dpop scope in their RFC8414 / OIDC Discovery 1.0 documents `scopes_supported` parameter and have client's check that before using it?</div><div><br></div><div><div dir="ltr" class="gmail_signature">S pozdravem,<br><b>Filip Skokan</b></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Aug 2025 at 14:30, Thomas Broyer 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="auto"><div><div>It doesn't "contradict the spirit of OAuth", as it is spec'd that way: <a href="https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1" target="_blank">https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1</a></div><div dir="auto"><br></div><div dir="auto">IMO it was an error for OpenID Connect to be spec'd with this wording though (maybe there's a good reason for ignoring unknown scopes, it should then have been documented in the spec).</div><div><br></div><div><div dir="ltr">Thomas Broyer<br><a href="https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu" target="_blank">/tɔ.ma.bʁwa.je/</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 28 août 2025, 14:13, Jacob Ideskog via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> a écrit :<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>Hi all,</div><div><br></div><div>I was reading the OpenID Keybinding spec and found something I think will be breaking compatibility.</div><div><br></div><div>In section 1.5 it states:</div><div><br></div><div>"If the OP does not support the <code style="font-family:monospace">dpop</code> scope, it MUST return an error response with the error code <code style="font-family:monospace">invalid_scope</code> per [RFC6749] 5.2."</div><div><br></div><div>This contradicts the spirit of OAuth and OpenID Connect where unknown parameters in general should be ignored if not understood.</div><div><br></div><div>But for scope specifically the OpenID Connect spec 3.1.2.1 states:</div><div><br></div><div>"Scope values used that are not understood by an implementation SHOULD be ignored"</div><div><br></div><div>So an existing OP that knows nothing about the dpop scope could by default simply drop it. It sounds like this is trying to enforce behaviour on non compliant OPs that they by default wouldn't have.</div><div><br></div><div>Perhaps I missed something.</div><div><br></div><div>Regards</div><div>Jacob</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:small"></span>Jacob Ideskog<br><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>CTO<br></div><div>Curity<br></div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span><div><a href="https://www.google.com/maps/search/Sankt+G%C3%B6ransgatan+66,+Stockholm,+Sweden?entry=gmail&source=g" target="_blank">Sankt Göransgatan 66, Stockholm, Sweden</a><br>M: <a value="+46727255655" style="color:rgb(17,85,204)" rel="noreferrer">+46 70-2233664</a><br><font style="color:rgb(0,153,0)"><a href="mailto:jacob@twobo.com" style="color:rgb(17,85,204)" rel="noreferrer" target="_blank">j</a><a href="mailto:acob@curity.io" rel="noreferrer" target="_blank">acob@curity.io</a></font></div></div><div><font style="color:rgb(0,153,0)"><a href="http://curity.io" rel="noreferrer" target="_blank">curity.io</a></font></div><div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer 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>
_______________________________________________<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>
</blockquote></div>
</blockquote></div>
</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><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:small"></span>Jacob Ideskog<br><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>CTO<br></div><div>Curity<br></div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span><div><a href="https://www.google.com/maps/search/Sankt+G%C3%B6ransgatan+66,+Stockholm,+Sweden?entry=gmail&source=g" target="_blank">Sankt Göransgatan 66, Stockholm, Sweden</a><br>M: <a value="+46727255655" style="color:rgb(17,85,204)">+46 70-2233664</a><br><font style="color:rgb(0,153,0)"><a href="mailto:jacob@twobo.com" style="color:rgb(17,85,204)" target="_blank">j</a><a href="mailto:acob@curity.io" target="_blank">acob@curity.io</a></font></div></div><div><font style="color:rgb(0,153,0)"><a href="http://curity.io" target="_blank">curity.io</a></font></div><div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span></div></div></div></div></div></div></div></div></div></div>
</blockquote></div></div>
</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>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:small"></span>Jacob Ideskog<br><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>CTO<br></div><div>Curity<br></div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span><div>Sankt Göransgatan 66, Stockholm, Sweden<br>M: <a value="+46727255655" style="color:rgb(17,85,204)">+46 70-2233664</a><br><font style="color:rgb(17,85,204)" color="#009900"><a href="mailto:jacob@twobo.com" style="color:rgb(17,85,204)" target="_blank">j</a><a href="mailto:acob@curity.io" target="_blank">acob@curity.io</a></font></div></div><div><font style="color:rgb(17,85,204)" color="#009900"><a href="http://curity.io" target="_blank">curity.io</a></font></div><div><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">------------------------------</span><span style="color:rgb(136,136,136)">-------</span></div></div></div></div></div></div></div></div></div></div>