<div dir="ltr">The argument against enabling command tokens to be encrypted is that all RPs would need to support decrypting command tokens. While we could allow an RP to include a flag to indicate support for encrypted command tokens, the metadata command would need to be unencrypted, so making it optional for an RP to support seems even more complicated. <br><br>Does anyone have any solid use cases for requiring command tokens to be encrypted?<br><br>SCIM does not encrypt its content besides the use of HTTPS as far as I know<br><br>/Dick<br><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 13, 2025 at 5:15 PM 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>