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

[Dick Hardt]

A further clarification on OP Commands vs SCIM.

OP Commands are for federations using OpenID Connect. From what I see in
the market, SCIM deployments are typically paired with a SAML deployment,
not OpenID Connect deployments. OP Commands provides a simple path for OIDC
RPs to upgrade to providing full account lifecycle support.

Or am I missing a bunch of OIDC deployments that use SCIM?

/Dick

On Wed, Jan 15, 2025 at 12:29 PM Dick Hardt <dick.hardt at gmail.com> 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_-6800859992948440431_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_-6800859992948440431_section-1-1.3>
>
> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
> <#m_-6800859992948440431_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_-6800859992948440431_section-1-1.5>
>
> *3. Are OpenID Provider Commands a replacement for SCIM, Shared Signals,
> or RISC?* <#m_-6800859992948440431_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_-6800859992948440431_section-1-1.7>
>
> *4. Why are there only groups? Why not roles and entitlements?*
> <#m_-6800859992948440431_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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250217/83407dbb/attachment.htm>