[Openid-specs-ab] OpenID Provider Commands - proposed WG specification

[Brian Campbell]

During the WG call yesterday there was some discussion of this OpenID
Provider Commands proposal and I was asked to put a few sentences about my
feedback on the mailing list so that
it'd be on record. Aaron did a nice job with the thankless job of minute
taking in that meeting
https://lists.openid.net/pipermail/openid-specs-ab/2025-January/010577.html
and his parahpahsing of my words and the conversations seems totally
sufficient for that purpose. So I'm copying relevant parts here:


Dick: ...  In discussions with people I've gotten a fair amount of positive
feedback.
...
Brian: You've also had not positive feedback to the idea. I have mixed
feelings about this, I don't think that SCIM or SCIM Events or RISC/CAEP
really hit the mark, so I have some sympathy for trying to produce the same
results in a simpler way. But I am similarly concerned that this is yet
another attempt at the same problem that will further crowd the landscape
and confuse everyone. This is both a note of support and pushback. Logout
is another area that has failed us all.

Dick: My understanding of your feedback was worried about there being
another protocol. The SAML people also told us we didn't need OpenID
Connect, but it's widely deployed because it solves things simpler.

Brian: I don't think the equivalency between SAML and OpenID Connect. That
said, I'd love to see something people actually use instead of the ongoing
hype about all the problems that RISC/CAEP will solve for us.

On Wed, Jan 15, 2025 at 5:30 AM Dick Hardt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hello WG (and chairs)
>
> 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"
>
> We contribute the IP in the attached HTML and Markdown files to the OpenID
> Foundation per the Foundations IPR.
>
> We have a FAQ as a note at the top, that I am including below for your
> convenience.
>
> We hope this work is of interest to others in the WG, and that together we
> can improve the security posture of implementers.
>
> /Dick & Karl
>
> *1. How does SCIM compare to OpenID Provider (OP) Commands?*
> <#m_-3250992085103549817_section-1-1.2>
>
> 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. <#m_-3250992085103549817_section-1-1.3>
>
> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
> <#m_-3250992085103549817_section-1-1.4>
>
> 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. <#m_-3250992085103549817_section-1-1.5>
>
> *3. Are OpenID Provider Commands a replacement for SCIM, Shared Signals,
> or RISC?* <#m_-3250992085103549817_section-1-1.6>
>
> 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.
> <#m_-3250992085103549817_section-1-1.7>
>
> *4. Why are there only groups? Why not roles and entitlements?*
> <#m_-3250992085103549817_section-1-1.8>
>
> 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.
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250131/87b098ed/attachment.htm>