<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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.<br>
</li>
</ul>
<p><br>
</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix">On 15/01/2025 14:29, Dick Hardt via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD9ie-tyovVqMs_RBUg4-Tg2fnK-7CjRKe_L_bhiNvvJzZ69JQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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="gmail-section-1-1.2"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><strong>1.
How does SCIM compare to OpenID Provider (OP) Commands?</strong></p>
<p id="gmail-section-1-1.3"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">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="gmail-section-1-1.4"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><strong>2.
How do Shared Signals / RISC compare to OpenID Provider
Commands?</strong></p>
<p id="gmail-section-1-1.5"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">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="gmail-section-1-1.6"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><strong>3.
Are OpenID Provider Commands a replacement for SCIM,
Shared Signals, or RISC?</strong></p>
<p id="gmail-section-1-1.7"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">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="gmail-section-1-1.8"
style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><strong>4.
Why are there only groups? Why not roles and
entitlements?</strong></p>
<p id="gmail-section-1-1.9"
style="padding:0px;margin:0px;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">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 class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-ab">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>