[Openid-specs-ab] The dpop scope compatibility

Thu Aug 28 15:27:20 UTC 2025

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