[Openid-specs-ab] client_id vs aud claim (Re: Review of OpenID Provider Commands (draft 00))

[george at practicalidentity.com]

+1 for this approach

It might be useful to put the full URI in the `aud` claim so that domain matches can be made as well

George Fletcher
Identity Standards Architect
Practical Identity LLC



> On Mar 14, 2025, at 7:33 AM, Dick Hardt via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> 
> 
> On Fri, Mar 14, 2025 at 12:51 AM Joseph Heenan <joseph at authlete.com <mailto:joseph at authlete.com>> wrote:
>> Hi Dick,
>> 
>> 
>> > On 14 Mar 2025, at 01:01, Dick Hardt via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>> > 
>> > 
>> > Building on Joseph's response:
>> > > The confusion attack only really applies where you have a ‘sub’ value that can contain a client id or a user identifier. That isn’t the case here.
>> > 
>> > An objective is to have a Command Token that is used in the `activate` and `maintain` commands to be able to be verified and processed similar to an id_token allowing code reuse.
>> > 
>> > the id_token specifies that the client_id is the `aud` claim, so following that same semantic keeps things simple for the RP
>> > 
>> > We do want to provide mechanisms that make it easy for an RP to not confuse id_tokens and command tokens -- We can add that the command claim MUST NOT be in an id_token, and per the other thread, we could require OPs that support OP Commands to require a nonce in the id_token. 
>> 
>> Unfortunately I think it’s not just the RP that we need to worry about - whilst doing so is contentious, there are various patterns of third parties accepting id tokens, and we should at least be aware of the implications if one of those third parties would accept a command token in place of an id_token.
> 
> I'm not that familiar with those patterns Joseph. Would you share those so we can reflect on how to minimize the risk of a command_token being used in place of an id_token?
> 
> Perhaps Andrii's proposal (if I understood it correctly) of the `aud` being the commands_uri and the `client_id` claim containing the client_id is the better approach. It seems this would significantly reduce the risk of token confusion.
> 
> The command token endpoint then knows the command was intended for it, and it and the `client_id` is then just a claim in the command. This may simplify RPs that host multiple client tenants that are each identified by their own client_id value
> 
> The example at the end of section 4 would then change from 
> 
> {
>   "iss": "https://op.example.org <https://op.example.org/>",
>   "sub": "248289761001",
>   "aud": "s6BhdRkqt3",
>   "iat": 1734004000,
>   "exp": 1734004060,
>   "jti": "bWJr",
>   "command": "unauthorize",
> }
> 
> to 
> 
> {
>   "iss": "https://op.example.org <https://op.example.org/>",
>   "aud": "https://rp.example.net/commands",
>   "sub": "248289761001",
>   "client_id": "s6BhdRkqt3",
>   "iat": 1734004000,
>   "exp": 1734004060,
>   "jti": "bWJr",
>   "command": "unauthorize",
> }
> 
> where https://rp.example.net/commands is the commands_uri
> _______________________________________________
> 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/20250314/59cdcebb/attachment.htm>