<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:0 0 0 40px;border:none;padding:0px"><div><i>{</i></div><div><i>  "iss": "<a href="https://op.example.org">https://op.example.org</a>",</i></div><div><i>  "sub": "248289761001",</i></div><div><i>  "aud": "<a href="https://rp.example.org">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">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">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)</a>.<br><br>2. An OP should be able to encrypt OP Commands using encryption keys(s) when they are available in the <a href="https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata">Client's Metadata.</a><br><br>3. I suggested enabling nested groups in section "6.1 Metadata Command". Are there particular reasons for having and allowing only a plain structure? That shouldn't be a big issue to remove this limitation in the way I see it. Nested groups offer convenience and simplify their and permission management.<br><br>4. I don't think I clearly understand what's the goal of claim "domains" in section "6.1 Metadata Command". If they are vendor specific, I'd suggest removing them from the spec altogether. It shouldn't be an issue to add them, as well as other claims, if a particular implementation / vendor needs them.<br><br>5. I suggest using the claim "member_of" instead of "group" in OP Commands such as the activate command.<br><br>6. I find it a bit odd how an OP retrieves the metadata from an RP. For that it needs to push its metadata first (using the POST HTTP Method) and then it retrieves the Metadata Response (Section 6.2). I would like to have more clarification on this matter (yes, I know this is the very first draft).<br><br>7. It would be great to know if there is any interest to have partial upgrades of the RP Metadata using  JSON Merge Patch (RFC 7386). That would be very convenient in some cases, for instance, an OP just wants to add and remove a few groups, etc.<br><br></div><div>All the best,</div><div>Andrii</div><div><br></div></div>