<div dir="ltr"><div dir="ltr"><div dir="ltr"><br>Building on Joseph's response:</div><div dir="ltr">> 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.</div><div dir="ltr"><br></div><div>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.<br><br>the id_token specifies that the client_id is the `aud` claim, so following that same semantic keeps things simple for the RP<br><br>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. </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com">andrii.deinega@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi WG,<br><br>Wanted to send some feedback and suggestions a bit earlier... but didn't have enough time for that.<div><br></div><div>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<br><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><i>{</i></div><div><i>  "iss": "<a href="https://op.example.org" target="_blank">https://op.example.org</a>",</i></div><div><i>  "sub": "248289761001",</i></div><div><i>  "aud": "<a href="https://rp.example.org" target="_blank">https://rp.example.org</a>",</i></div><div><i>  "client_id": "client1234567890"</i></div><div><i>  "iat": 1734003000,</i></div><div><i>  "exp": 1734003060,</i></div><div><i>  "jti": "bWJq",</i></div><div><i>  "command": "activate",</i></div><div><i>  "given_name": "Jane",</i></div><div><i>  "family_name": "Smith",</i></div><div><i>  "email": "<a href="mailto:jane.smith@example.org" target="_blank">jane.smith@example.org</a>",</i></div><div><i>  "email_verified": true,</i></div><div><i>  "tenant": "ff6e7c9",</i></div><div><i>  "groups": [</i></div><div><i>    "b0f4861d",</i></div><div><i>    "88799417"</i></div><div><i>  ]</i></div><div><i>}</i></div></blockquote><div><br>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 <a href="https://datatracker.ietf.org/doc/html/rfc9068" target="_blank">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)</a>.<br></div></div></blockquote><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div>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 <a href="https://datatracker.ietf.org/doc/html/rfc9700" target="_blank">the Best Current Practice for OAuth 2.0 Security (RFC 9700)</a>, what I did is "simply" applied this to OP Commands.</div></div></div>
</blockquote></div></div>