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

[Andrii Deinega]

Dick, yes, your example properly illustrates my suggestion. It's safe to
say it becomes even more important when dealing with multi-tenant OPs. You
never want a malicious actor to trick an OP into creating a client with a
specific name to abuse RPs in different tenants (due to lack of controls /
checks on either or both sides).

It's also worth noting that the aud claim can take not only a single string
but also an array of strings, as specified in the OpenID Connect Core 1.0
spec.

On a side note, one day OpenID Connect ID Tokens will be explicitly
typed... along with Logout Tokens, and JWT assertions used as client's
credentials.

https://bitbucket.org/openid/connect/issues/2162/recommendation-to-the-use-of-explicit


All the best,

Andrii



On Fri, Mar 14, 2025 at 8:03 AM george--- via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Dick,
>
> My apologies! I read the “command” claim as the “aud” claim which of
> course doesn’t (and shouldn’t) have the full URL.
>
> George Fletcher
> Identity Standards Architect
> Practical Identity LLC
>
>
>
> On Mar 14, 2025, at 10:59 AM, Dick Hardt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> 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
>>
>>
>> _______________________________________________
> 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/20250314/e7205e15/attachment.htm>