[Openid-specs-ab] Review of OpenID Provider Commands (draft 00)

[Joseph Heenan]

On 13 Mar 2025, at 06:53, Andrii Deinega via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:

On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com<mailto:dick.hardt at gmail.com>> wrote:


On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com<mailto:andrii.deinega at gmail.com>> wrote:
Hi WG,

Wanted to send some feedback and suggestions a bit earlier... but didn't have enough time for that.

1. I suggest extending Section 4 (Command Token) with a new required claim (client_id) to help prevent and address potential misuse and abuse. Thus, one of the provided examples for the command token (activate) becomes to look like this

{
  "iss": "https://op.example.org<https://op.example.org/>",
  "sub": "248289761001",
  "aud": "https://rp.example.org<https://rp.example.org/>",
  "client_id": "client1234567890"
  "iat": 1734003000,
  "exp": 1734003060,
  "jti": "bWJq",
  "command": "activate",
  "given_name": "Jane",
  "family_name": "Smith",
  "email": "jane.smith at example.org<mailto:jane.smith at example.org>",
  "email_verified": true,
  "tenant": "ff6e7c9",
  "groups": [
    "b0f4861d",
    "88799417"
  ]
}

The key idea is that the aud claim includes (one or more) RP URLs where the client_id claim "carries" the client identifier. Note, this is in line with JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)<https://datatracker.ietf.org/doc/html/rfc9068>.

I'd prefer clarifying that the `aud` is the `client_id`, and has a single value. Is there a motivation for having the `aud` and `client_id` be different?

Once you put "client_id" in the aud claim, you became a vulnerable for confusion attacks for those OPs (and authorization servers) that allow clients to influence their client_ids, I didn't make this up, this is part of the Best Current Practice for OAuth 2.0 Security (RFC 9700)<https://datatracker.ietf.org/doc/html/rfc9700>, what I did is "simply" applied this to OP Commands.

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.

The “typ” header (as already used in the provider command spec) avoids confusion with other types of token, and as this token is defined to only have ‘client_id’ in aud there’s no chance of confusion between client ids and user identifiers.

I think there probably is a small chance of confusion with an id_token though (the command token appears to pass all/most of the rules for validating an id_token as per https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation ). I’m not sure if that is a real problem, but if it is it would probably be best to put the client id into “client_id” and have no “aud”. “Client url” seems to be a new concept that we don’t have right now, I can’t see how it helps to introduce a new “client url” concept just to use in “aud” here.

Joseph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250313/26081807/attachment-0001.htm>