[Openid-specs-ab] The dpop scope compatibility

Fri Aug 29 13:48:38 UTC 2025

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.
I would suggest adding an explanation similar to what Filip wrote above to
an "Implementation Considerations" section.
Perhaps something like:
"Some OpenID Providers may choose not to include the dpop scope in the list
of supported_scopes of their OpenID Connect Metadata Document. When using
such an OpenID Provider, Relying Parties SHOULD NOT add the dpop scope to
requests unless they can gracefully handle that the cnf claim is not
present in the returned ID token."

On Fri, 29 Aug 2025 at 14:09, Dick Hardt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Changes made:
>
> - aligned `dpop` being unknown by OP with OpenID Connect specifications
> - added metadata SHOULD for `dpop` scope and
> `dpop_signing_alg_values_supported`
> - added some c_hash changes that were missed earlier
> - added Acknowledgements
> - fixed references
>
> https://github.com/dickhardt/openid-key-binding
>
>
>
> On Fri, Aug 29, 2025 at 8:06 AM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> 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.
>>
>> On Fri, Aug 29, 2025 at 7:51 AM Jacob Ideskog <jacob.ideskog at curity.io>
>> wrote:
>>
>>>  I had not noticed the discrepancy between  OAuth and OIDC on the
>>>> treatment of unroecognized scopes
>>>
>>>
>>> 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.
>>> 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.
>>>
>>> > 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.
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> /Jacob
>>>
>>>
>>> On Thu, 28 Aug 2025 at 17:28, Dick Hardt via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> Thanks for the clarification.
>>>>
>>>> Note we are talking about an OP -- not an AS
>>>>
>>>> I had not noticed the discrepancy between  OAuth and OIDC on the
>>>> treatment of unroecognized scopes.
>>>>
>>>> On Thu, Aug 28, 2025 at 4:11 PM Filip Skokan <panva.ip at gmail.com>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> > 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> S pozdravem,
>>>>> *Filip Skokan*
>>>>>
>>>>>
>>>>> On Thu, 28 Aug 2025 at 17:02, Dick Hardt <dick.hardt at gmail.com> wrote:
>>>>>
>>>>>> Filip: Are you suggesting that the OP should ignore the scope if not
>>>>>> supported, or should return an error?
>>>>>>
>>>>>> From your comment are you suggesting that the OP MUST or SHOULD
>>>>>> support discovery of the scopes supported?
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> On Thu, Aug 28, 2025 at 3:10 PM Filip Skokan <panva.ip at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> S pozdravem,
>>>>>>> *Filip Skokan*
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 28 Aug 2025 at 16:05, Dick Hardt via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>
>>>>>>>> I have no strong opinion on how this should work in the key binding
>>>>>>>> document.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 28, 2025 at 2:31 PM Renato Athaydes via Openid-specs-ab
>>>>>>>> <openid-specs-ab at lists.openid.net> wrote:
>>>>>>>>
>>>>>>>>> > What is the point of this requirement?
>>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> When you could just let the server "ignore" unknown scopes, and
>>>>>>>>> the client would continue working happily with only the valid scopes it
>>>>>>>>> requested.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Renato Athaydes
>>>>>>>>>
>>>>>>>>> On Thu, Aug 28, 2025 at 2:57 PM Filip Skokan via Openid-specs-ab <
>>>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>>>
>>>>>>>>>> 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 3.1.2.1.
>>>>>>>>>> Authentication Request
>>>>>>>>>> <https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest> (as
>>>>>>>>>> Jacob already pointed out).
>>>>>>>>>>
>>>>>>>>>> Scope values used that are not understood by an implementation
>>>>>>>>>>> SHOULD be ignored.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> S pozdravem,
>>>>>>>>>> *Filip Skokan*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 28 Aug 2025 at 14:30, Thomas Broyer via Openid-specs-ab <
>>>>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>>>>
>>>>>>>>>>> It doesn't "contradict the spirit of OAuth", as it is spec'd
>>>>>>>>>>> that way:
>>>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1
>>>>>>>>>>>
>>>>>>>>>>> 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).
>>>>>>>>>>>
>>>>>>>>>>> Thomas Broyer
>>>>>>>>>>> /tɔ.ma.bʁwa.je/
>>>>>>>>>>> <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
>>>>>>>>>>>
>>>>>>>>>>> Le jeu. 28 août 2025, 14:13, Jacob Ideskog via Openid-specs-ab <
>>>>>>>>>>> openid-specs-ab at lists.openid.net> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I was reading the OpenID Keybinding spec and found something I
>>>>>>>>>>>> think will be breaking compatibility.
>>>>>>>>>>>>
>>>>>>>>>>>> In section 1.5 it states:
>>>>>>>>>>>>
>>>>>>>>>>>> "If the OP does not support the dpop scope, it MUST return an
>>>>>>>>>>>> error response with the error code invalid_scope per [RFC6749]
>>>>>>>>>>>> 5.2."
>>>>>>>>>>>>
>>>>>>>>>>>> This contradicts the spirit of OAuth and OpenID Connect where
>>>>>>>>>>>> unknown parameters in general should be ignored if not understood.
>>>>>>>>>>>>
>>>>>>>>>>>> But for scope specifically the OpenID Connect spec 3.1.2.1
>>>>>>>>>>>> states:
>>>>>>>>>>>>
>>>>>>>>>>>> "Scope values used that are not understood by an implementation
>>>>>>>>>>>> SHOULD be ignored"
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps I missed something.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Jacob
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jacob Ideskog
>>>>>>>>>>>> CTO
>>>>>>>>>>>> Curity
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> -------
>>>>>>>>>>>> Sankt Göransgatan 66, Stockholm, Sweden
>>>>>>>>>>>> <https://www.google.com/maps/search/Sankt+G%C3%B6ransgatan+66,+Stockholm,+Sweden?entry=gmail&source=g>
>>>>>>>>>>>> M: +46 70-2233664
>>>>>>>>>>>> j <jacob at twobo.com>acob at curity.io
>>>>>>>>>>>> curity.io
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> -------
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-ab mailing list
>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>
>>>>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>
>>>
>>> --
>>> Jacob Ideskog
>>> CTO
>>> Curity
>>> -------------------------------------------------------------------
>>> Sankt Göransgatan 66, Stockholm, Sweden
>>> <https://www.google.com/maps/search/Sankt+G%C3%B6ransgatan+66,+Stockholm,+Sweden?entry=gmail&source=g>
>>> M: +46 70-2233664
>>> j <jacob at twobo.com>acob at curity.io
>>> curity.io
>>> -------------------------------------------------------------------
>>>
>> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250829/4201c4ef/attachment-0001.htm>