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

Thu Sep 4 16:54:20 UTC 2025

Hi Dick,

I’m a little confused by ‘bound_key’ as the purpose of the scope is not to create a “bound key” but rather to bind a key to a token and more specifically the id_token. When I think of scopes like ‘openid’ or ‘profile’ I generally have a decent idea of the intent of the scope. Would ‘bound_token’ work? The intended result is a bound token?

George Fletcher
Identity Standards Architect
Practical Identity LLC

> On Sep 4, 2025, at 12:44 PM, Dick Hardt <dick.hardt at gmail.com> wrote:
> 
> I'm going to update the name of the scope in the doc to be "bound_key" unless there is opposition to it / or someone has a suggestion they prefer for us to discuss!
> 
> On Sat, Aug 30, 2025 at 11:07 AM Dick Hardt <dick.hardt at gmail.com <mailto:dick.hardt at gmail.com>> 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 <mailto: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 <mailto: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 <mailto:openid-specs-ab at lists.openid.net>>
>>> Cc: Dag Helge Østerhagen <dag at udelt.no <mailto:dag at udelt.no>>; george at practicalidentity.com <mailto:george at practicalidentity.com> <george at practicalidentity.com <mailto:george at practicalidentity.com>>; Filip Skokan <panva.ip at gmail.com <mailto: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 <mailto: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 <mailto:george at practicalidentity.com> <george at practicalidentity.com <mailto: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 <mailto:openid-specs-ab at lists.openid.net>>
>>> Cc: Dag Helge Østerhagen <dag at udelt.no <mailto: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 <mailto: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 <mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of george--- via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>>
>>>> Sent: Friday, August 29, 2025 6:14:16 PM
>>>> To: Dick Hardt <dick.hardt at hello.coop <mailto:dick.hardt at hello.coop>>
>>>> Cc: george at practicalidentity.com <mailto:george at practicalidentity.com> <george at practicalidentity.com <mailto:george at practicalidentity.com>>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/20250904/c9fd0946/attachment-0001.htm>