[Openid-specs-ab] The dpop scope compatibility

[Dick Hardt]

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/e6638e15/attachment.htm>