[Openid-specs-ab] The dpop scope compatibility

Fri Aug 29 06:51:05 UTC 2025

>
>  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
M: +46 70-2233664
j <jacob at twobo.com>acob at curity.io
curity.io
-------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250829/fb14d63b/attachment-0001.htm>