[Openid-specs-ab] Key-binding and dpop scope

Wed Sep 3 15:54:49 UTC 2025

If you just want to have the scope be added by default, it is not a large
departure -- but I'm unclear why including the scope and the dpop_jkt is
not viable.

On Wed, Sep 3, 2025 at 4:51 PM Kosuke Koiwai <kkoiwai at gmail.com> wrote:

> That is true Dick.
> However, diverting from standards poses some risks of patents and
> maintenance costs. I would like to know if anyone in the field shares the
> problems.
>
> Kosuke
>
> 2025年8月30日(土) 22:17 Dick Hardt <dick.hardt at gmail.com>:
>
>> You can do whatever you want in your application Kosuke!
>>
>> A standardized spec enables software written by different parties to
>> interoperate. From my recollection, your use case is a single party. You
>> can ignore the authentication request part if you want. You won't have
>> quite the same security characteristics if the client does not
>> include dpop_jkt as a parameter.
>>
>> On Sat, Aug 30, 2025 at 2:09 PM Kosuke Koiwai <kkoiwai at gmail.com> wrote:
>>
>>> Can we separate the spec to add cnf to id_token and how to ask for it?
>>>
>>> As I asked before, I want to add the key info to id_token, and the key
>>> is the same as the one used for attestation-based client auth.
>>>
>>>
>>> https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010892.html
>>>
>>> I want to add the cnf claim at the discretion of IdP, so RP doesn’t have
>>> to add any to the scope.
>>>
>>> Kosuke
>>>
>>>
>>> On Sat, Aug 30, 2025 at 19:07 Dick Hardt via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> "bound_key" is crisper and says what is wanted in the token rather than
>>>> what is to be done
>>>>
>>>> On Fri, Aug 29, 2025 at 6:51 PM Dag Helge Østerhagen via
>>>> Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>>> +1 for both "key_binding" and "cnf". Sigh.
>>>>>
>>>>> /dag
>>>>> ------------------------------
>>>>> *From:* Dick Hardt <dick.hardt at gmail.com>
>>>>> *Sent:* Friday, August 29, 2025 7:47:45 PM
>>>>> *To:* Artifact Binding/Connect Working Group <
>>>>> openid-specs-ab at lists.openid.net>
>>>>> *Cc:* Dag Helge Østerhagen <dag at udelt.no>;
>>>>> george at practicalidentity.com <george at practicalidentity.com>; Filip
>>>>> Skokan <panva.ip at gmail.com>
>>>>> *Subject:* Re: [Openid-specs-ab] Key-binding and dpop scope
>>>>>
>>>>> `key_binding` as scope name?
>>>>>
>>>>> On Fri, Aug 29, 2025 at 6:35 PM Dag Helge Østerhagen via
>>>>> Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>> Well,  currently the dpop header is used to signal token binding (and
>>>>> inclusion of the cnf claim) for access and refresh tokens.   I don't see
>>>>> any other use cases in the (near) future.
>>>>>
>>>>> /dag
>>>>> ------------------------------
>>>>> *From:* george at practicalidentity.com <george at practicalidentity.com>
>>>>> *Sent:* Friday, August 29, 2025 7:01:54 PM
>>>>> *To:* Artifact Binding/Connect Working Group <
>>>>> openid-specs-ab at lists.openid.net>
>>>>> *Cc:* Dag Helge Østerhagen <dag at udelt.no>
>>>>> *Subject:* Re: [Openid-specs-ab] Key-binding and dpop scope
>>>>>
>>>>> My thought is that might depend on whether the ‘cnf’ scope is only
>>>>> applied to the id_token or whether cnf claims should be added to other
>>>>> issued tokens as well. Currently the proposed key-binding spec is specific
>>>>> to id_tokens.
>>>>>
>>>>> George Fletcher
>>>>> Identity Standards Architect
>>>>> Practical Identity LLC
>>>>>
>>>>>
>>>>>
>>>>> On Aug 29, 2025, at 12:56 PM, Dag Helge Østerhagen via Openid-specs-ab
>>>>> <openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>> I like «id_token_cnf», but wouldn’t just «cnf» be more aligned with
>>>>> other oidc scopes?
>>>>>
>>>>> /dag
>>>>> ------------------------------
>>>>> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
>>>>> behalf of george--- via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net>
>>>>> *Sent:* Friday, August 29, 2025 6:14:16 PM
>>>>> *To:* Dick Hardt <dick.hardt at hello.coop>
>>>>> *Cc:* george at practicalidentity.com <george at practicalidentity.com>;
>>>>> Artifact Binding/Connect Working Group <
>>>>> openid-specs-ab at lists.openid.net>
>>>>> *Subject:* Re: [Openid-specs-ab] Key-binding and dpop scope
>>>>>
>>>>> That makes sense to me; including ‘cnf’ in the scope name. Would we
>>>>> ever want to allow the “key binding” mechanism to use something other than
>>>>> DPoP? If so, and the express purpose is to provide key binding for the
>>>>> id_token, then I’d recommend something like ‘id_token_cnf’.  It’s specific,
>>>>> clear and doesn’t preclude methods other than DPoP to provide the necessary
>>>>> data for the cnf claim.
>>>>>
>>>>> George Fletcher
>>>>> Identity Standards Architect
>>>>> Practical Identity LLC
>>>>>
>>>>>
>>>>>
>>>>> On Aug 29, 2025, at 11:00 AM, Dick Hardt <dick.hardt at hello.coop>
>>>>> wrote:
>>>>>
>>>>> I have no strong views on the scope name. Open to other ideas /
>>>>> suggestions / opinions!
>>>>>
>>>>> Perhaps `cnf` to align with the claim?
>>>>> ᐧ
>>>>>
>>>>> On Fri, Aug 29, 2025 at 3:57 PM <george at practicalidentity.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Would it make sense to change the scope name identified in the
>>>>> key-binding spec from something specific like ‘dpop’ to something more
>>>>> generic? e.g. ‘id_token_kb’ ? Or maybe just make clearer that the RP is
>>>>> looking for key bound tokens? e.g. ‘dpop_kb’? I just worry that ‘dpop’ by
>>>>> itself does not communicate the intended behavior.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> George Fletcher
>>>>> Identity Standards Architect
>>>>> Practical Identity LLC
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20250903/c93e62f2/attachment-0001.htm>