[Openid-specs-ab] The dpop scope compatibility

[Filip Skokan]

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/4d491e01/attachment-0001.htm>