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

[Dick Hardt]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250314/a4c30254/attachment.htm>