<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 8:47 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">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 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><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" target="_blank">Client's Metadata.</a></div></div></blockquote><div><br></div><div>Why would that be useful? It might not be currently specified, but the commands_uri MUST be HTTPS, so secrecy is provided between OP and RP.</div><div> </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><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></div></div></blockquote><div><br>Would you elaborate on how this would work? What would it mean if a group was in a group for a user? While groups can be made up of groups when defining a group, the account either belongs to a group or not. <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><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></div></div></blockquote><div><br></div><div>These are DNS domains controlled by the tenant, and are a common way for an RP to determine if accounts belong to the same organization. </div><div> </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><br>5. I suggest using the claim "member_of" instead of "group" in OP Commands such as the activate command.<br></div></div></blockquote><div><br></div><div>Why?<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><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></div></div></blockquote><div><br></div><div>Part of the OP metadata that the RP requires to respond is the OP tenant for the Command as the RP may provide different metadata for different tenants. <br><br>The OP metadata may also provide different metadata for different RPs (as identified by aud). Passing the OP metadata to the RP and then the RP responding with its metadata seemed efficient. <br><br>The groups metadata claim enables the id and display of a group to be provided once. This allows the groups claim to be an array of identifiers rather than the SCIM approach where it is an array of objects with redundant data.<br><br></div><div> </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><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></div></div></blockquote><div><br></div><div>It would be great to know!<br><br>Currently the spec strives for simplicity and full transfers in the metadata, as well as in the tenant_audit response, and in the activate and maintain commands. We are trading simpler code paths for using more bandwidth.<br><br>If there are a massive number of groups, SCIM is likely a better protocol as it allows direct management of groups as a resource, where OP commands only manages accounts, and groups is a claim about the account.</div><div><br></div><div><br><br></div><div> </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><br></div><div>All the best,</div><div>Andrii</div><div><br></div></div>
</blockquote></div></div>