<div dir="ltr"><div dir="ltr">Adding to Aaron's comments.<div><br></div><div>The account and tenant information is all managed by the OP, and the OP knows when it changes, so the OP knows when to push the changes to the RP. Telling the RP to pull the data seems inefficient, and this approach allows the RP to be passive and receive data when it changes. </div><div><br></div><div>But perhaps I am missing something in our suggestions. Can you elaborate on why you are suggesting that and what the advantages might be?</div><div><br>Related: Karl and I have pondered how can the RP tell the OP it wants the metadata again. One approach would be the OP provides that functionality in its RP management console.</div><div><br></div><div> </div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025 at 2:27 PM Aaron Parecki 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="auto">Vladimir, I understand the thought behind this suggestion, but I think it only adds unnecessary complexity. </div><div dir="auto"><br></div><div dir="auto">The value of this draft comes from leveraging the existing relationship and configuration between the RP and IdP, namely that the RP is necessarily already configured to validate signed ID tokens, and this draft builds on that to send signed tokens with the same signing key so that there isn't another credential to configure and maintain.</div><div dir="auto"><br></div><div dir="auto">Alternatively, making the RP fetch the data means forcing the RP to maintain an access token, defining an API request and response vocabulary, defining endpoint discovery for the API, etc, much more work on both ends for little benefit.</div><div dir="auto"><br></div><div dir="auto">Aaron</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025 at 4:00 AM Vladimir Dzhuvinov / Connect2id 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"><u></u>
<div>
<p>Dick, Karl, hi.</p>
<p>Interesting draft.</p>
<p>I'm wondering whether the messaging and the overall architecture
could be simplified by sending simple "state changed" JWTs from OP
to RP. Instead of "command+data" JWTs.<br>
</p>
<ul>
<li>The "account" and "tenant" are protected resources at the OP.<br>
<br>
</li>
<li>The "account" and "tenant" resources have a clearly designated
current state / status, e.g. "active".<br>
<br>
</li>
<li>If the state changes the OP sends a "state changed" JWT.<br>
<br>
</li>
<li>The RP can always check / poll the resource (for changes, or
if it suspects a missed JWT). Cache headers could be used to
hint when to recheck.<br>
<br>
</li>
<li>The resource may provide a history of the changes.</li></ul></div><div><ul><li><br>
</li>
</ul>
<p><br>
</p>
<pre cols="72" style="font-family:monospace">Vladimir Dzhuvinov</pre>
<div>On 15/01/2025 14:29, Dick Hardt via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">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"
<div><br>
</div>
<div>We contribute the IP in the attached HTML and Markdown
files to the OpenID Foundation per the Foundations IPR. </div>
<div><br>
</div>
<div>We have a FAQ as a note at the top, that I am including
below for your convenience.</div>
<div><br>
</div>
<div>We hope this work is of interest to others in the WG, and
that together we can improve the security posture of
implementers.</div>
<div><br>
</div>
<div>/Dick & Karl<br>
<br>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.2" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;color:rgb(17,17,17)"><strong style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">1.
How does SCIM compare to OpenID Provider (OP) Commands?</strong></p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.3" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;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.</p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.4" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;color:rgb(17,17,17)"><strong style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">2.
How do Shared Signals / RISC compare to OpenID Provider
Commands?</strong></p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.5" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;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.</p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.6" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;color:rgb(17,17,17)"><strong style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">3.
Are OpenID Provider Commands a replacement for SCIM,
Shared Signals, or RISC?</strong></p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.7" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;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.</p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.8" style="padding:0px;margin:0px 0px 1em;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;color:rgb(17,17,17)"><strong style="font-family:"Noto Sans",Arial,Helvetica,sans-serif">4.
Why are there only groups? Why not roles and
entitlements?</strong></p>
<p id="m_7495092910391231179m_-7026078826930531320gmail-section-1-1.9" style="padding:0px;margin:0px;font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px;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.<br>
<br>
</p>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" style="font-family:monospace" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" style="font-family:monospace" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</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></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>