<div dir="ltr">I support adoption and wish this was part of my toolkit today (a simple way to manage accounts and groups).<div><br><div>I have no strong preference regarding a new tenant claim and how it should be passed around for an entity such as a user or group. For instance, it could look like an additional property for the subject identifier (RFC 9493) or maybe... something else. At the end of the day, what matters to me is there is some (reached) agreement on how to do it in this, or in other specs. Having said that, I believe an OP shouldn't have control over how an RP manages its tenants (I refer to OP Commands such as suspend_tenant and delete_tenant).</div></div><div><br></div><div>The OP Commands spec implies that an RP must be available for an OP. I think we can do that a bit better, we can address use cases when RPs aren't available for OPs (those are native clients, wallets, etc.). To solve this we can leverage the WebSocket Protocol (RFC 6455) creating bidirectional communication channels between involved parties, and I advocate for that.</div><div><br></div><div>All the best,</div><div>Andrii</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 5, 2025 at 12:37 AM Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</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"><div dir="ltr">There is an additional precedence in the OIDF related to the SSE topic. Not only did the logout specs introduce the session concept and define the `sid` claim for use in logout as well as in an ID Token, the back channel logout used Security Event Token (SET) as its format for a command, despite SecEvents explicitly stating "<span style="color:rgb(0,0,0);font-size:13.3333px">Security events are not commands issued between parties."<br></span></div><div dir="ltr"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div dir="ltr"><a href="https://www.rfc-editor.org/rfc/rfc8417.html#:~:text=Security%20events%20are%20not%20commands%20issued%20between%20parties" target="_blank">https://www.rfc-editor.org/rfc/rfc8417.html#:~:text=Security%20events%20are%20not%20commands%20issued%20between%20parties</a>.<div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 4, 2025 at 6:38 PM Karl McGuinness <<a href="mailto:me@karlmcguinness.com" target="_blank">me@karlmcguinness.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">There is prior art in the working group to what Dick and I proposed with defining the tenant claim within the OP Commands spec. The <a href="https://openid.net/specs/openid-connect-frontchannel-1_0.html" target="_blank">OpenID Connect Front-Channel Logout</a> spec registered the <b><font face="monospace">sid</font></b> claim to identify a session in an ID Token which was defined as<dl style="color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial,sans-serif"><dt>sid</dt><dd>OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">sid</tt> values are used to identify distinct sessions at an OP. The <tt style="color:rgb(0,51,102);font-family:"Courier New",Courier,monospace">sid</tt> value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier.</dd></dl><div>The <a href="https://openid.net/specs/openid-connect-backchannel-1_0.html" target="_blank">OpenID Connect Back-Channel Logout</a> then reuses the <b><font face="monospace">sid</font></b> claim registration used in ID Tokens as a Logout Token parameter. </div><div><br></div><div>Sessions like tenants are just as fundamental of concept to an authentication system and stripe across many use cases that may be defined in different specs. The family of logout specs didn't pull out the <b><font face="monospace">sid</font></b> claim to its own spec and require the reader/implementor to go read yet another spec, they instead defined the relevant parts within the spec and just reused the claim registration even if it's used in an ID Token. OP Commands is proposing a similar approach with the <b><font face="monospace">tenant</font></b> claim. As Dick has stated on the working group call that over time it may then make sense to cut an OIDC 1.1 update that is similar in spirit to OAuth 2.1 that consolidates all these extensions that revises the core protocol and concepts in a single document.</div><div><br></div><div>-Karl</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 4, 2025 at 8:43 AM Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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"><div dir="ltr"><div dir="ltr"><b>Tenant</b><br><br>Here is what the OP Commands proposal has about OP tenants:</div><div dir="ltr"><br>>>>>>><br><ul style="padding:0px;margin:0px 0px 1em 2em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><li id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-6.6" style="margin:0px 0px 0.25em"><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-6.6.1" style="padding:0px;margin:0px"><strong>tenant</strong><br>REQUIRED.<br>A JSON string. The Tenant identifier. MAY have the value <code style="background-color:rgb(248,248,248);font-size:13.3px">personal</code>, <code style="background-color:rgb(248,248,248);font-size:13.3px">organization</code> or a stable OP unique value for multi-tenant OPs. The <code style="background-color:rgb(248,248,248);font-size:13.3px">personal</code> value is reserved for when Accounts are managed by individuals. The <code style="background-color:rgb(248,248,248);font-size:13.3px">organization</code> value is reserved for Accounts are managed by an organization.<a href="https://dickhardt.github.io/openid-provider-commands/openid-provider-commands-1_0-00.html#section-4-6.6.1" style="text-decoration-line:none;color:rgb(102,102,102)" target="_blank"></a></p></li></ul><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">The combination of <code style="background-color:rgb(248,248,248);font-size:13.3px">iss</code> and <code style="background-color:rgb(248,248,248);font-size:13.3px">tenant</code> uniquely identifies a Tenant.<br>>>>>>></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">I'm happy to see that I did call out that it is the combination of `iss` and `tenant` that uniquely identifies a Tenant. <br><br>I fail to see how it is a benefit to an implementer of OP Commands to have this text in an independent document, nor why an OP can't start including the tenant claim in ID Tokens if they choose to do so even if it is defined in OP Commands. They are unlikely to care now about adding in the tenant claim unless they are also looking to deploy OP Commands.<br><br></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>Tenant management / SSE</b></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">The only required command in OP Commands is the `tenant_metadata` command, which lets the OP know which commands the RP supports for a given OP tenant. This is the starting point of protocol negotiation between the OP and the RP. Having that command be in a separate document does not make sense. </p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">In order for an existing RP deployment to migrate to using OP Commands, the OP will want to do an audit of what accounts the RP already has, so I view the `tenant_audit` command to not be an extension, but a core command. <br><br>While SSE is a novel approach to syncing, as part of developing OP Commands is to experiment and see if SSE works better than pagination. I think it will be based on my experience in implementing both pagination and SSE. If not, then we can fall back to pagination.</p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">I think we want the audit command in the core document and I once again fail to see the benefit to an implementer in having it in a separate document.<br><br>The other tenant commands are a tenant wide version of one of the other commands.</p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">In other words "<span style="font-family:Arial,Helvetica,sans-serif;font-size:small">containing everything from the "Tenant Commands" section" is not going to work as an independent document if you dive in and think of what an implementer will need to do.</span></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>NOTE:</b> just because we have specified all this functionality, does not mean that an RP must implement it all. All commands except for tenant_metadata are optional. An RP can pick what it wants to deploy, and can roll out new functionality as needed. For example, an RP may just do `delete` and `unauthorize`. </p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">I'm reminded of how OAuth 2.0 got separated into RFC 6749 and RFC 6750 and the friction that added. I feel very strongly that this should all be in one document.</p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">Karl and I have spent a bunch of time pondering how this works. We have made many changes based on other's feedback that improved the doc. The suggestion to break it apart does NOT improve things.</p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">/Dick</span></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></p><p id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174gmail-section-4-7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><br></p></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 4, 2025 at 4:11 PM Aaron Parecki <<a href="mailto:aaron@parecki.com" target="_blank">aaron@parecki.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">The three work streams would be:<div><ul><li>OpenID Connect Tenants - defines the "tenant" claim and adds the claim to ID tokens</li><li>OP Commands - containing most of the first half of the current OP Commands draft, describing the command request/response, the command tokens, account lifecycle commands. References the Tenants document for the tenant claim.</li><li>OP Tenant Management - containing everything from the "Tenant Commands" section, including defining the SSE streaming API.</li></ul></div><div>This enables us to standardize the concept of tenants in OpenID Connect Core, and lets the experimental use of SSE evolve independently of the more straightforward OP Command Tokens.</div><div><br></div><div>Aaron</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 4, 2025 at 7:09 AM Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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>
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt">As a point of clarification, what would these three work streams be? As an exercise to make this abundantly clear, would you and/or Aaron consider describing them in terms of a proposed document title and
abstract for each? In particular, the proposed abstract should say what problem is being solved by the draft and possibly also describe how it is being solved.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"> Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"> -- Mike (chair hat on)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Dean Saxe via Openid-specs-ab<br>
<b>Sent:</b> Tuesday, March 4, 2025 7:02 AM<br>
<b>To:</b> <a href="mailto:Dick.Hardt@gmail.com" target="_blank">Dick.Hardt@gmail.com</a>; Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Dean Saxe <<a href="mailto:dean.saxe@beyondidentity.com" target="_blank">dean.saxe@beyondidentity.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] Call for Adoption of the OpenID Provider Commands Specification<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">After spending time talking with Aaron and others about this draft during OSW, I support Aaron’s position. There is a lot of good that can come from this work. Breaking this into three separate work streams is the best path to move forward
and ensure robust discussion on each of the component parts.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-dhs<br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">--<u></u><u></u></p>
<div>
<p class="MsoNormal">Dean H. Saxe, <a href="https://idpro.org/cidpro/" target="_blank">CIDPRO</a> (he/him)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Principal Engineer<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Office of the CTO<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Beyond Identity<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="mailto:dean.saxe@beyondidentity.com" target="_blank">dean.saxe@beyondidentity.com</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Feb 22, 2025 at 11:06:20<span style="font-family:Arial,sans-serif"> </span>AM, Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">I strongly disagree with you based on the feedback I got on earlier drafts that I circulated, and your arguments are not convincing me otherwise.<br>
<br>
The tenant and audit functionality was not in the earliest drafts. I added the tenant and audit functionality based on feedback from early reviews.<br>
<br>
<b>tenant</b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">While not standardized in OpenID Connect, the tenant concept is captured in Microsoft and Google ID Tokens. OpenID has had many years to work on standardizing the tenant claim, but has not, and we now have a world of bespoke tenant claims.
Given that some OPs will require RPs to understand tenants, I view the tenant claim as a requirement for OP Commands. Additionally, the concept of a tenant needs to be a first class concept for all the commands as it provides a context within an issuer. If
an OpenID Connect Core 1.1 comes along, then it can add it as a claim in the ID Token, but let's help interoperability for OP Commands by embracing the tenant concept as a first class concept and not try tacking it on later. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><b>audit</b> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">While not all RPs will need to support audit some will for either brown field, or to ensure the OP and RP are in sync. How to sync was a common question on the first draft, and I consider it a required feature in OP Commands for many RPs
to adopt. RPs that don't need it can ignore that section, just as they do with many other specs. Those that do are not forced to go look at a different document.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Similarly, many clients do not need refresh tokens in OAuth 2.0. It was a concept that did not exist in OAuth 1.0, but it enabled long lived authorization for those that needed it. While refresh tokens could have been a different spec,
that would have added complexity and confusion. Separating OAuth 2.0 into what became RFC 6749 and RFC 6750 was a mistake driven by Erin, that I regret not taking the time to reverse before publication. We are fixing that in OAuth 2.1, which also incorporates
a number of other drafts that were created after 2.0. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><b>SSE</b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Audit requires sending a large amount of data from the RP to the OP when the number of users scales. Sending that as a single response to a request becomes impractical at some point. SCIM solved it with pagination, and I would argue as
an afterthought when someone realized that sending a single response would be impractical. Pagination is hard to implement at scale because you have to maintain the state of what you have sent so far across sessions. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">While SSE may not be what we land on for audit, I think it is much simpler for an RP to implement than pagination. The RP can get the data however it wants and start writing it to the stream. Session disconnections are handled by the libraries
transparently at both the server and client. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I don't expect anyone to be sold yet on SSE being the right choice, but having it in the document gives us something to discuss, and makes it clear that there are challenges with pagination.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">/Dick<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 21, 2025 at 11:50<span style="font-family:Arial,sans-serif"> </span>PM Aaron Parecki <<a href="mailto:aaron@parecki.com" target="_blank">aaron@parecki.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Thanks for the detailed response, this context is helpful.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think the fact that you're able to say this much about the tenant concept and SSE in this reply speaks a great deal to how these are relatively complex topics that warrant their own discussion. I'm not comfortable adopting this draft
wholesale, because I don't think this draft is necessarily the right layer to introduce these concepts to OpenID Connect.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The tenant problem is a great example as you mentioned, since Google and Microsoft both have different ways they handle the tenant concept. This should ultimately be standardized in OpenID Connect Core so that there is a standard way to
include the tenant in ID tokens regardless of whether the OP is using OP Commands.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I am still not convinced that SSE is actually an easier alternative to pagination compared to what is being done in SCIM. I suspect there are also plenty of edge/error cases that will come up with SSE as a syncing mechanism that will require
their own creative solutions down the road. Yes there are currently server-side client libraries of SSE, but they are not necessarily being used for data synchronization the way SSE is applied here. Plus, as you mentioned, SSE is used for the tenant audit
which is for brownfield implementations, so it's entirely possible an implementation would never need to build this, which suggests this would be better as a separate draft as well.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yes, having separate drafts can make things more complex for readers in the short term. But OAuth 2.1 brings together a carefully selected set of drafts from the past 12 years of OAuth. If OAuth had been created all as a massive single
draft at the beginning, it would be even more of a mess than it is today. So I don't think putting these three new concepts into a single new OpenID draft is a good path forward.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Aaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 21, 2025 at 1:14<span style="font-family:Arial,sans-serif"> </span>PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hey Aaron, thanks for the feedback. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">I think these are important points to discuss, but that I would prefer to have the discussion once the WG has decided to adopt the draft so that we can capture all the discussion in the repo rather than this
list so that it is easier for others to find the discussion.<br>
<br>
With that being said, and knowing that I will need to copy this content into the repo later on, here is why I think we want to keep tenant and SSE concepts in the draft:<u></u><u></u></p>
</div>
<p class="MsoNormal"><b>tenant</b><u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
The tenant concept is threaded through all of the draft, not just the tenant commands. The "tenant" claim is required in all of the commands. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">While the tenant concept has not been standardized in OpenID, Google includes a tenant claim "hd" in Google Workspace ID Tokens, and Microsoft includes "tid" in their ID Tokens. Microsoft has a unique issuer for each tenant, but Google
does not. In order for Google to adopt OP Commands, we need to provide a standard tenant mechanism, otherwise they will need to add a non-standard claim to their commands to communicate with the tenant. I would like to keep the barrier to adoption by Google
as low as possible, and for RP libraries not to have custom code to support Google.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The tenant commands include the tenant_metadata, the only command that an RP MUST implement. The tenant_audit command is needed for brown field adoption for the RP to add OP Commands, and an OP to understand the current state. IE, the OP
needs it to get the starting state when OP Commands are enabled. A brand new RP could decide to not support tenant_audit for simplicity, but not having tenant_audit would be a barrier for adoption for some existing RP / OP deployments.<br>
<br>
The other commands are tenant wide versions of the other commands. An RP can choose to not support them. I did notice in the OpenID Slack wg-sharedsignals that someone wanted to know how to send a signal for a tenant, and it was suggested the set the subject
to:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal">{<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> "format": "complex",<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> "tenant": "tenant-whose-users-were-revoked"<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">}<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I agree that the tenant claim is not OP Commands specific, and that it may make sense to have a separate document for it, and If the WG wants to specify the tenant claim as a separate document, I'm fine with that, but I strongly believe
the tenant claim needs to be used in OP Commands, and so we should adopt the document as is and then we can decide if we want to separate them out or not, as the tenant claim doc would need to exist for it to be used by OP Commands. <br>
<br>
Per the motivation to create OAuth 2.1, I also think having a large number of documents makes it harder for people to grasp everything, so I would argue that perhaps OP Commands introduces the tenant claim and gets it registered in IANA. Note that OP Commands
is also defining the group claim, which is currently underspecified.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><b>SSE</b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You are correct that using SSE between servers is a non-traditional use of SSE, and that client libraries are not as abundant as server libraries for SSE. The fact that there are client libraries indicates that there are server implementations.
Also it is the OP that is the client here, which is the party where we want to push complexity, and server libraries are readily available for an RP to use. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think it adds complexity long term to have more than one way for the RP to send a response, and given that SSE is pretty straightforward and addresses one of the complexity challenges in SCIM (pagination) we should keep it in the draft
so that we are forced to address how the RP will send a large response back to the OP in an audit. While we might not decide on SSE -- we don't want to punt on a mechanism for working at scale. <br>
<br>
>From an implementation point of view, simple, new RPs don't need SSE if they don't need to support any tenant commands other than tenant_metadata, which is required. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">/Dick<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 21, 2025 at 4:56<span style="font-family:Arial,sans-serif"> </span>PM Aaron Parecki via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I took another look at the draft after the discussion on the last call, and I have concerns about the current state of the document and think it should be revised before adopting it. I realize changes are possible after adoption, but I
believe the scope of the current document is too broad, and should be narrowed before adoption.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In general I am supportive of a lighter weight way to achieve most of what is described in this draft. I like that the command tokens leverage the existing signing key that RPs already use to validate ID tokens. The account lifecycle commands
are well thought out and I appreciate the state transition diagram in the draft.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">However, I have concerns about the Tenant commands as well as the use of Server-Sent Events.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The Tenant commands bring in a new concept that does not exist elsewhere in OpenID Connect today. I understand the goal here, but I am not convinced this draft is the right place to introduce this concept. This would be better off as a
separate OpenID Connect extension that extends both OpenID Connect Core and OP Commands to add the Tenant concept.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The use of Server-Sent Events is somewhat unusual here. It technically works, but the API is actually defined in HTML as an API to allow a web server to stream content to a web browser. I am personally a huge fan of SSE as it's easier to
deploy in web servers compared to Websockets. Using it for server-to-server communications is a somewhat non-traditional application of the technology. While it would work, I am concerned that it is not the best tool for the job, since there are far fewer
server-side SSE client libraries since most of the use is where the client is the web browser. That said, I am not entirely opposed to using it this way, I just worry that bringing it in to the OP Commands draft this early might backfire on the other more
easily understood patterns in the draft.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This is all to say that I would support adopting a version of this draft that describes only the account lifecycle commands with HTTP delivery as described in the first half of the document, and remove the Tenant commands and SSE delivery
mechanisms.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Aaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 20, 2025 at 1:18<span style="font-family:Arial,sans-serif"> </span>PM Michael Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">This starts a two-week call for feedback on whether to adopt the OpenID Provider Commands specification contributed to the working group by Dick Hardt
and Karl McGuiness as an OpenID Connect Working Group specification. Please reply-all by Thursday, March 6<sup>th</sup> saying whether you are favor of adoption or not, briefly also saying why.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">You can read more about the decision made on today’s working group call to start a call for adoption in the
<a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-February/010620.html" target="_blank">
minutes written by John Melati</a>.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> Writing as a working group chair,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> -- Mike
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>
<br>
<b>Sent:</b> Wednesday, January 15, 2025 4:30 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Cc:</b> Karl McGuinness <<a href="mailto:me@karlmcguinness.com" target="_blank">me@karlmcguinness.com</a>>; Michael Jones <<a href="mailto:michael_b_jones@hotmail.com" target="_blank">michael_b_jones@hotmail.com</a>>; Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>;
John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><br>
<b>Subject:</b> OpenID Provider Commands - proposed WG specification</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Hello WG (and chairs)<br>
<br>
Karl (cc'ed) and I have been working on a new protocol that complements OpenID Connect for an OP to centrally manage account lifecycles at RPs. We have also defined an Unauthorize Command which undoes whatever actions an RP did in a previous OpenID Connect
login -- useful if an OP suspects an account or device had been compromised -- instructs an RP to "kill all the sessions and tokens"<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We contribute the IP in the attached HTML and Markdown files to the OpenID Foundation per the Foundations IPR. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We have a FAQ as a note at the top, that I am including below for your convenience.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We hope this work is of interest to others in the WG, and that together we can improve the security posture of implementers.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">/Dick & Karl<br>
<br>
<u></u><u></u></p>
<p style="margin-bottom:12pt"><strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">1. How does SCIM compare to OpenID Provider (OP) Commands?</span></strong><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.3">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">The SCIM protocol is a general purpose protocol for a client to manage resources at a server. When the SCIM protocol is used between an IdP and an RP, the schema is defined by the
RP. The resources managed are in the context of the RP Tenant in a multi-tenant RP. Any extensions to the schema are defined by the RP. This provided an interoperable protocol to manage RP resources. OpenID Provider Commands are an extension of a user Account
created by OpenID Connect. It uses the same identity Claims that the OP issues for the user. It uses the same token Claims, and is verified the same way. OpenID Provider Commands are issued in the context of the OP Tenant in a multi-tenant OP.</span><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.4">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">2. How do Shared Signals / RISC compare to OpenID Provider Commands?</span></strong><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.5">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">Shared Signals and RISC are events that one party is sharing with another party. The actions a receiving party takes upon receiving a signal are intentionally not defined. The actions
taken by the RP when receiving an OpenID Provider Command is specified. This gives an OP control over the Account at the RP.</span><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.6">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">3. Are OpenID Provider Commands a replacement for SCIM, Shared Signals, or RISC?</span></strong><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.7">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">No. These standards are deployed by organizations that have complex requirements, and these standards meet there needs. Most OP / RPs do not deploy any of these standards, as the
implementation complexity is not warranted. OpenID Provider Commands are designed to build on OpenID Connect, allowing RPs using OpenID Connect an easy path to offer OPs a standard API for security and lifecycle operations.</span><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.8">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">4. Why are there only groups? Why not roles and entitlements?</span></strong><u></u><u></u></p>
<p style="margin-bottom:12pt" id="m_-2313964097218709291m_8800122629782051221m_7624762719783677174m_5385097624760382469m_6207901379283364259m_9126074971044289233m_-340431066711246023m_-6617812940805398432m_8380237628063331605m_-9121673182393254570m_-7103686937483258216gmail-section-1-1.9">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)">OpenID Provider Commands are used to project the Tenant data managed centrally by the OP. Groups are a common term used by OPs to manage a collection of Accounts. The terms roles
and entitlements tend to be RP specific. Generally, groups from the OP will be mapped to roles and/or entitlements that are RP specific, at the RP.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></blockquote></div>
</blockquote></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>