<div dir="ltr"><div dir="ltr">On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><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">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 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 class="gmail_quote"><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><div><br></div><div>These days, you typically don't get an end-to-end TLS session between the involved parties, there are all sorts of intermediaries that perform TLS offloading, deep packet inspection (DPI) and whatnot. But, I can also turn your question around - why does OpenID Connect Core spec allow encrypting its ID Tokens?</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 class="gmail_quote"><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></div></div></blockquote><div><br></div><div>First of all, RPs can make use of the structure of groups (how they are nested in each other) alone, I'd even say that in some cases, it's very desirable to have this piece of information. Secondly, you don't need to indicate in OP Commands such as "activate" that user1 is a member of group1.1 when this group is included in group1.</div><div><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 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><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><div><br></div><div>What you described seems to be vendor specific details. I never said they aren't needed, these details simply don't necessarily need to be part of the spec.</div><div><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 class="gmail_quote"><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></div></div></blockquote><div><br></div><div>I'd say it's because of all my prior LDAP experience (specifically MS flavor of it), I'd love to hear other opinions from the WG.</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 class="gmail_quote"><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>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></div></div></div></blockquote><div><br></div><div>I'd love to hear other opinions from the WG on that.</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 class="gmail_quote"><div><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></div></blockquote><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 class="gmail_quote"><div><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>
</blockquote></div></div>