<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>I support adoption of this specification.</p>
<p>I think it may significantly simplify various use cases where we
currently need multiple protocols. I also think it may help an
organisation operating an OP in GDPR compliance as this mechanism
will allow them to assert direct controle over accounts in remote
RPs.</p>
<p>Niels<br>
</p>
<div class="moz-cite-prefix">On 20/02/2025 22:17, Michael Jones via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite" cite="mid:PH7PR02MB92925630144FF51215C11F0DB7C42@PH7PR02MB9292.namprd02.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;}@font-face
{font-family:"Noto Sans";}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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" moz-do-not-send="true">
minutes written by John Melati</a>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
Writing as a working group chair,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">
-- Mike
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Dick Hardt <a class="moz-txt-link-rfc2396E" href="mailto:dick.hardt@gmail.com"><dick.hardt@gmail.com></a>
<br>
<b>Sent:</b> Wednesday, January 15, 2025 4:30 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Cc:</b> Karl McGuinness <a class="moz-txt-link-rfc2396E" href="mailto:me@karlmcguinness.com"><me@karlmcguinness.com></a>;
Michael Jones <a class="moz-txt-link-rfc2396E" href="mailto:michael_b_jones@hotmail.com"><michael_b_jones@hotmail.com></a>; Nat
Sakimura <a class="moz-txt-link-rfc2396E" href="mailto:sakimura@gmail.com"><sakimura@gmail.com></a>; John Bradley
<a class="moz-txt-link-rfc2396E" href="mailto:ve7jtb@ve7jtb.com"><ve7jtb@ve7jtb.com></a><br>
<b>Subject:</b> OpenID Provider Commands - proposed WG
specification<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></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"<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We have a FAQ as a note at the top,
that I am including below for your convenience.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">/Dick & Karl<br>
<br>
<br>
<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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:#111111"><o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.3">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.4">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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:#111111"><o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.5">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.6">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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:#111111"><o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.7">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.8">
<strong><span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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:#111111"><o:p></o:p></span></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:0in" id="gmail-section-1-1.9">
<span style="font-size:10.5pt;font-family:"Noto Sans",sans-serif;color:#111111">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.<o:p></o:p></span></p>
</div>
</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>