[Openid-specs-ab] Call for Adoption of the OpenID Provider Commands Specification

Karl McGuinness me at karlmcguinness.com
Mon Mar 3 08:18:30 UTC 2025 

Mike, thanks for calling for feedback on our OpenID Provider Commands
specification. I strongly support its adoption as it addresses a critical
gap for modern apps seeking enterprise readiness.

Today, enterprises can enforce security controls like MFA during SSO but
lack a standardized way to manage sessions and accounts post-SSO. This is
especially problematic in cases where apps maintain "offline" access to
enterprise-protected resources such as using OAuth 2.0 Refresh and Access
Tokens without OP policy enforcement.  The OP may never see additional
authentication requests after a user successfully signs-in to an app.

While existing protocols like SCIM or the Shared Signals Framework can
help, they introduce significant cost and complexity, particularly for
early-stage apps without revenue from a large enterprise customer base.
Many developers also face constraints from app frameworks, tech stack, or
service providers that make adopting new infrastructure, services, and
protocols challenging. As a result, these protocols are often deferred by
long-tail apps that lack formal enterprise contracts or dedicated IT
governance such as core systems of record apps like CRM or ERP.  Given the
choice, app developers would rather invest in solving a new customer
challenge than learning a new identity protocol.

OIDC's success partially stems from its developer-friendly approach,
balancing implementation cost with customer value. It has enabled SaaS
startups to onboard millions of enterprise users through seamless
integrations like "Sign-in with Google," driving both adoption and
revenue.  App developers can reuse existing libraries and integrations
(hopefully with OIDC certified implementation!) with an increasingly
diverse set of app models, hosting architectures, and service providers to
have apps live with OIDC-based SSO in minutes. If an app can redirect, host
a callback route, and make an outbound HTTPS request to the OP then it can
integrate SSO!

This specification follows the same philosophy, offering an incremental
path for developers to meet enterprise security needs without excessive
complexity.

With OpenID Provider Commands:

   - Developers can validate OP Command JWTs using the existing OP root of
   trust (JWKS), avoiding the need to securely store and manage credentials or
   implement additional OAuth infrastructure like an Authorization Server
   - Enterprises can enforce post-SSO security controls such as session or
   account revocation using the same RP->OP relationship established during
   SSO.
   - Adoption is flexible allowing enterprises to define required and
   optional commands.  For example an enterprise can choose to only allow SSO
   to apps that also support the unauthorize command.  This leaves room for
   profiling such as IPSIE

By simplifying enterprise readiness for long-tail enterprise
app developers, this specification ensures that OIDC remains the most
accessible and scalable choice for modern identity. I encourage adoption to
fill this critical gap and strengthen enterprise identity management for
the rapidly growing OIDC ecosystem

-Karl


On Thu, Feb 20, 2025 at 1:18 PM Michael Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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 6th saying whether you are favor of
> adoption or not, briefly also saying why.
>
>
>
> You can read more about the decision made on today’s working group call to
> start a call for adoption in the minutes written by John Melati
> <https://lists.openid.net/pipermail/openid-specs-ab/2025-February/010620.html>
> .
>
>
>
>                                                 Writing as a working group
> chair,
>
>                                                                 -- Mike
>
>
>
> *From:* Dick Hardt <dick.hardt at gmail.com>
> *Sent:* Wednesday, January 15, 2025 4:30 AM
> *To:* openid-specs-ab at lists.openid.net
> *Cc:* Karl McGuinness <me at karlmcguinness.com>; Michael Jones <
> michael_b_jones at hotmail.com>; Nat Sakimura <sakimura at gmail.com>; John
> Bradley <ve7jtb at ve7jtb.com>
> *Subject:* OpenID Provider Commands - proposed WG specification
>
>
>
> 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?*
>
> 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.
>
> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
>
> 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.
>
> *3. Are OpenID Provider Commands a replacement for SCIM, Shared Signals,
> or RISC?*
>
> 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.
>
> *4. Why are there only groups? Why not roles and entitlements?*
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250303/2136d935/attachment-0001.htm>

More information about the Openid-specs-ab mailing list