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

[Dick Hardt]

On Sat, Mar 15, 2025 at 3:58 AM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> 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).
>

The one proposal I worry about is where the client_id is a URL per
https://www.ietf.org/id/draft-parecki-oauth-client-id-scheme-01.html --
this could be the same URL as the commands_uri for a client, so the `aud`
and `client_id` in a Command Token would have the same value.


>
> 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.
>

I have the opinion that allowing the `aud` claim to be an array was an edge
case that overly complicated token processing.


> 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
>

I think the odds of existing deployments updating id_tokens to be
explicitly typed to be low. We could specify in OP Commands that an OP that
supports OP Commands SHOULD explicitly type their tokens. That does not
help all the RPs that are not coded to look for it though.


>
> 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/20250315/4b373b29/attachment.htm>