[Openid-specs-ab] The dpop scope compatibility

Sat Aug 30 09:44:10 UTC 2025

Thanks Dick, the changes look great.

On Fri, 29 Aug 2025 at 15:48, Frederik Krogsdal Jacobsen <
frederik.krogsdal at criipto.com> wrote:

> I think the recent changes fix this issue. I agree with Jacob that it is
> sometimes necessary to over-explain to avoid wrong assumptions from
> implementers.
> I would suggest adding an explanation similar to what Filip wrote above to
> an "Implementation Considerations" section.
> Perhaps something like:
> "Some OpenID Providers may choose not to include the dpop scope in the
> list of supported_scopes of their OpenID Connect Metadata Document. When
> using such an OpenID Provider, Relying Parties SHOULD NOT add the dpop
> scope to requests unless they can gracefully handle that the cnf claim is
> not present in the returned ID token."
>
> On Fri, 29 Aug 2025 at 14:09, Dick Hardt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> 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
>>>> -------------------------------------------------------------------
>>>>
>>> _______________________________________________
>> 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/20250830/cc291f66/attachment-0001.htm>