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

[Andy Barlow]

I support adoption of this draft by the working group.

I think Aaron raises some interesting questions and I agree we should look
more closely at them - I am unsure of the implications of adopting a draft,
and I may be being naive, but as a newcomer it is my understanding that the
main points of concern can be later removed / split out to separate
specifications, hence my support for adopting the draft - If I understand
correctly a majority consensus would be needed by all of the WG
participants..

I am particularly interested in the use of SSE in this draft -  I share the
concerns raised by others, and would very much like to get my hands on /
have a play with the code to better understand an implementation of this.

Andy

On Thu, Feb 20, 2025 at 9: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/20250306/f9efd655/attachment.htm>