<div dir="ltr"><div>In addition to being defined by IANA in <a href="https://datatracker.ietf.org/doc/html/rfc9068">JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens</a> which was based on SCIM's decision to use "groups" as the user schema attribute for a list of groups to which the user belongs,  many enterprise IdPs like Entra ID and Okta already use the claim name "groups" in an ID token for group memberships.   Microsoft has used the SAML claim name "<a href="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">http://schemas.microsoft.com/ws/2008/06/identity/claims/groups</a>" for over a decade with ADFS & .NET ecosystem.  I have seen more deployments that use "groups" today instead of "member_of" for expressing group memberships for a user in modern JSON based protocols vs the LDAP based implementation of "member_of". </div><div><br></div><div>-Karl</div><div><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 13, 2025 at 10:16 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@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"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 10:53 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"><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 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></div></div></blockquote></div></div></blockquote><div><snip></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 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>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><div><br></div><div>The core spec allows ID Tokens to be sent in the redirect (the implicit flow) which makes them visible to anything that can monitor browser URLs and could end up in server logs. That would be my guess on why it is in OpenID Connect Core -- but I was not one of the authors.</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"><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><div><br></div><div>groups is already a defined claim in IANA <br><br>I prefer groups -- but no strong opinion -- what do others think?<br><br></div><div> </div></div></div>
</blockquote></div></div>