[Openid-specs-ab] The dpop scope compatibility

Thu Aug 28 15:10:36 UTC 2025

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250828/6b735b1f/attachment-0001.htm>