<div dir="ltr">Note that OP Commands tenant concept is only in the context of the OP, not the RP. For RPs, I agree they generally think of tenant in the context of a set of users and their data. The OP and RP tenant are sometimes the same, and sometimes they are not. For OPs that use the same issuer for multiple OP tenants such as Google, the OP tenant concept is needed. <br><br>Like many words in this industry, a term often has different meanings in different contexts, and I agree tenant is one of those!<br><br><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 6, 2025 at 2:31 PM Brock Allen 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 id="m_4779454089588926939__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(26,26,26);text-align:left" dir="ltr"><div>I would like to voice some partial support for this proposal. </div><div><br></div><div><br></div><div>I do like the notion of a light weight OP-to-RP messaging mechanism around user account life cycle. Personally, I'd prefer to have something like SCIM-light in the other working group where work has already been taking place. But if that doesn't exist or isn't already underway, then perhaps it does make sense to move it forward here.</div>
<div><br></div><div><br></div>But, also I'd like to raise a concern about this proposal and the use of the tenant semantic and a tenant claim.<div><br></div><div>I know for many SaaS OPs out there, the design is to support an organization ("tenant") that has its own set of RPs which are unique to the tenant and distinct from other tenants. Users then are typically scoped to a particular tenant in these scenarios.<div><br></div><div>For many of the use cases I see, my customers use tenant differently. The tenant applies only to the users and the data those users access in the RP. In this case, there is only one set of RPs and those are used across all "tenants" by all users. Users might only be in one tenant, but they might also be in multiple tenants. </div><div><br></div><div>So in short, I'm concerned that the addition of a formal OIDC tenant claim that might disrupt or interfere with existing deployments semantics around their [pre-]existing tenant semantics. </div><div><br></div><div>I'm happy to have "tenant" explored and maybe even formalized somewhere, but I just wanted to voice that it's already an overloaded term.</div><div><br></div><div><br></div><div>Finally, the use SSE feels odd to be in a server-to-server scenario. I'd imagine that there other better designed mechanisms for this already out there?</div><div><br></div><div><div>-Brock<div><br></div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px">
<p style="color:rgb(170,170,170);margin-top:10px">On 2/20/2025 4:18:10 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:</p><div style="font-family:Arial,Helvetica,sans-serif">
<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.<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">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>.<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"> Writing as a working group chair,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"> -- Mike
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></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<u></u><u></u></span></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">/Dick & Karl<br>
<br>
<br>
<u></u><u></u></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in">
<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><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)"><u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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.<u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)"><u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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.<u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)"><u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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.<u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:rgb(17,17,17)"><u></u><u></u></span></p>
<p style="margin-right:0in;margin-bottom:12pt;margin-left:0in" id="m_4779454089588926939gmail-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.<u></u><u></u></span></p>
</div>
</div>
</div>
</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>
</blockquote></div>