<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Dick,<br>
</div>
<div class="moz-cite-prefix">On 23/01/2025 16:52, Dick Hardt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD9ie-v4Hv5KG0h=Em9sZspbVtTLX3dp3bEq5WZKHdJjXmzFKw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Vladimir
<div><br>
</div>
<div>By "enterprise app" are you referring to internal apps, or
a B2B SaaS app? Internal apps can have direct access to the
directory in many cases, so I'm assuming you are referring to
B2B SaaS apps.</div>
</div>
</blockquote>
<p>Both actually. In those cases when we dealt with internal apps to
be integrated via OIDC, the aim was to regulate access to the user
data via the OpenID provider, and close off LDAP access.</p>
<p>What I like about the "Commands" is that it may simplify the
necessary dealings for apps to be GDPR compliant. Managing that
via the OIDC layer looks appealing.<br>
</p>
<blockquote type="cite"
cite="mid:CAD9ie-v4Hv5KG0h=Em9sZspbVtTLX3dp3bEq5WZKHdJjXmzFKw@mail.gmail.com">
<div dir="ltr">
<div>In my experience, an app needs to have a robust DB of user
data. The OP knows when the data changes, so can push to the
RP whenever there is a change, To ensure there the data is in
sync in case a command was missed or something, the OP
occasionally can send a tenant_audit command to ensure the RP
has what the OP thinks it should have.</div>
</div>
</blockquote>
<p>The task to supply user data in an app, in a persistent and
well-structured fashion, looks easier when that's built on top of
a RESTful resource. Rather than on incoming RPC. App developers
are more comfortable with RESTful resources and there is more
available software to deal with that.<br>
</p>
<p>An OP resource for the accounts and tenants will not make the
JWTs to notify of state changes redundant. They'd still be useful
to tell the RP to update its state.<br>
</p>
<p>Vladimir<br>
</p>
<blockquote type="cite"
cite="mid:CAD9ie-v4Hv5KG0h=Em9sZspbVtTLX3dp3bEq5WZKHdJjXmzFKw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2025 at
8:43 AM Vladimir Dzhuvinov / Connect2id 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>
<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>On 16/01/2025 19:50, Dick Hardt via Openid-specs-ab
wrote:<br>
</div>
<blockquote type="cite">
<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">
<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"
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 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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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_95800757149584570m_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></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<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>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab"
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>
</blockquote>
</body>
</html>