[Openid-specs-ab] The dpop scope compatibility

Fri Aug 29 12:08:33 UTC 2025

Changes made:

- aligned `dpop` being unknown by OP with OpenID Connect specifications
- added metadata SHOULD for `dpop` scope and
`dpop_signing_alg_values_supported`
- added some c_hash changes that were missed earlier
- added Acknowledgements
- fixed references

https://github.com/dickhardt/openid-key-binding

On Fri, Aug 29, 2025 at 8:06 AM Dick Hardt <dick.hardt at gmail.com> wrote:

> Works for me. Thanks for noticing the discrepancy and the discussion. As
> we had no call yesterday for adoption I’ll make those changes to the
> proposal.
>
> On Fri, Aug 29, 2025 at 7:51 AM Jacob Ideskog <jacob.ideskog at curity.io>
> wrote:
>
>>  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
>> <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
>> -------------------------------------------------------------------
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250829/d4ea64c1/attachment-0001.htm>