<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Dick, hi Aaron,<br>
</p>
<p>If I were an enterprise app developer, having an "account" and
"tenant" resource hosted and managed for me by the OP would seem
like a great convenience. I'd be able to cache the account and
tenant data in my app, but that would not be so critical (as when
data is received via commands), because whenever I need to, I'd be
able to call upon an authoritative resource at the OP. If my app
misses a command, that would seem to be less of an issue. A simple
GET of the OP resource would always give me the correct current
state and account data.</p>
<p>Aaron, yes, an OP resource would require an access token. I
haven't thought through that. Could the signed JWT for the state
change be used as some form of authorisation?<br>
</p>
<p>The "account" and "tenant" data look similar to the UserInfo
resource we currently have in OIDC. With an added crucial feature,
to communicate state changes from OP to RP.</p>
<p>Vladimir</p>
<div class="moz-cite-prefix">On 16/01/2025 19:50, Dick Hardt via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD9ie-vnBVreYqcL5Hsu8S5fHWwYAP-tf=DbT7hyFCtsFO3Xfw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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>
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
style="font-family:monospace" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-ab@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</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 moz-txt-link-freetext"
href="mailto:Openid-specs-ab@lists.openid.net"
moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext"
href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
moz-do-not-send="true">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body>
</html>