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

[Dick Hardt]

The example I provided was the full URL George — what am I missing?

On Fri, Mar 14, 2025 at 2:55 PM <george at practicalidentity.com> wrote:

> +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>
> wrote:
>
>> Hi Dick,
>>
>>
>> > On 14 Mar 2025, at 01:01, Dick Hardt via Openid-specs-ab <
>> 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",
>   "sub": "248289761001",
>   "aud": "s6BhdRkqt3",
>   "iat": 1734004000,
>   "exp": 1734004060,
>   "jti": "bWJr",
>   "command": "unauthorize",
> }
>
> to
>
> {
>   "iss": "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
> 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/ca782a88/attachment-0001.htm>