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

Dick Hardt dick.hardt at gmail.com
Wed Mar 5 08:31:26 UTC 2025 

Brian: I read your email. Did you read my email and Karl's? If so, it's
disappointing that you could not be bothered to respond to either my points
or Karl's points. That leads me to believe that you are not interested in
having a discussion.

Your response reminds me of my early presentations to the IETF.  The
general consensus was that the IETF had protocols that solved identity.
After being told no 3 times, we took our toys and started the OpenID
Foundation to do the work.

I received similar feedback from Erin about what became OAuth 2.0. He did
not agree with the approach and refused to let it be called OAuth, so we
called it WRAP. When we presented it at IIW, the community revolted against
Erin.



On Wed, Mar 5, 2025 at 12:01 AM Brian Campbell <bcampbell at pingidentity.com>
wrote:

> I also generally support Aaron’s position.
>
> I have pushed back on adopting this work within this working group, in
> part due to concerns about yet another attempt to solve the same
> cross-domain account management problem. Introducing it here risks further
> crowding and confusing the landscape, especially given the implied
> endorsement and authority of the OIDF.
>
> The discussions so far haven’t really alleviated those concerns. However,
> I can understand the reasoning behind providing a simpler way for OPs to
> manage account lifecycles by leveraging existing OIDC
> constructs—specifically, using a token signed the same way as an ID token
> as the authentication and authorization mechanism for these calls.
>
> That said, the introduction of the tenancy concept and the rather
> unconventional use of part of the HTML living standard for server-to-server
> communication stray well beyond the premise of simplicity and leveraging
> established practices. I strongly object to WG adoption of the draft with
> those elements included.
>
> As a side note, SSE was originally the name of the working group
> responsible for RISC and CAEP before they changed the acronym to avoid
> conflicts with an analyst category.  Using SSE in this context to refer to
> HTML’s server-sent events (and mistakenly calling it "Server-Side Events"
> in the link) adds an unnecessary and confusing layer for those familiar
> with the history of that working group.
>
>
>
>
> On Tue, Mar 4, 2025 at 8:01 AM Dean Saxe via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> After spending time talking with Aaron and others about this draft during
>> OSW, I support Aaron’s position.  There is a lot of good that can come from
>> this work.  Breaking this into three separate work streams is the best path
>> to move forward and ensure robust discussion on each of the component parts.
>>
>> -dhs
>> --
>> Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/> (he/him)
>> Principal Engineer
>> Office of the CTO
>> Beyond Identity
>> dean.saxe at beyondidentity.com
>>
>>
>>
>>
>> On Feb 22, 2025 at 11:06:20 AM, Dick Hardt via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> I strongly disagree with you based on the feedback I got on earlier
>>> drafts that I circulated, and your arguments are not convincing me
>>> otherwise.
>>>
>>> The tenant and audit functionality was not in the earliest drafts. I
>>> added the tenant and audit functionality based on feedback from early
>>> reviews.
>>>
>>> *tenant*
>>>
>>> While not standardized in OpenID Connect, the tenant concept is captured
>>> in Microsoft and Google ID Tokens. OpenID has had many years to work on
>>> standardizing the tenant claim, but has not, and we now have a world of
>>> bespoke tenant claims. Given that some OPs will require RPs to understand
>>> tenants, I view the tenant claim as a requirement for OP Commands.
>>> Additionally, the concept of a tenant needs to be a first class concept for
>>> all the commands as it provides a context within an issuer. If an OpenID
>>> Connect Core 1.1 comes along, then it can add it as a claim in the ID
>>> Token, but let's help interoperability for OP Commands by embracing the
>>> tenant concept as a first class concept and not try tacking it on later.
>>>
>>> *audit*
>>>
>>> While not all RPs will need to support audit some will for either brown
>>> field, or to ensure the OP and RP are in sync. How to sync was a common
>>> question on the first draft, and I consider it a required feature in OP
>>> Commands for many RPs to adopt. RPs that don't need it can ignore that
>>> section, just as they do with many other specs. Those that do are not
>>> forced to go look at a different document.
>>>
>>> Similarly, many clients do not need refresh tokens in OAuth 2.0. It was
>>> a concept that did not exist in OAuth 1.0, but it enabled long lived
>>> authorization for those that needed it. While refresh tokens could have
>>> been a different spec, that would have added complexity and confusion.
>>> Separating OAuth 2.0 into what became RFC 6749 and RFC 6750 was a mistake
>>> driven by Erin, that I regret not taking the time to reverse before
>>> publication. We are fixing that in OAuth 2.1, which also incorporates a
>>> number of other drafts that were created after 2.0.
>>>
>>> *SSE*
>>>
>>> Audit requires sending a large amount of data from the RP to the OP when
>>> the number of users scales. Sending that as a single response to a request
>>> becomes impractical at some point. SCIM solved it with pagination, and I
>>> would argue as an afterthought when someone realized that sending a single
>>> response would be impractical. Pagination is hard to implement at scale
>>> because you have to maintain the state of what you have sent so far across
>>> sessions.
>>>
>>> While SSE may not be what we land on for audit, I think it is much
>>> simpler for an RP to implement than pagination. The RP can get the data
>>> however it wants and start writing it to the stream. Session disconnections
>>> are handled by the libraries transparently at both the server and client.
>>>
>>> I don't expect anyone to be sold yet on SSE being the right choice, but
>>> having it in the document gives us something to discuss, and makes it clear
>>> that there are challenges with pagination.
>>>
>>> /Dick
>>>
>>>
>>>
>>> On Fri, Feb 21, 2025 at 11:50 PM Aaron Parecki <aaron at parecki.com>
>>> wrote:
>>>
>>>> Thanks for the detailed response, this context is helpful.
>>>>
>>>> I think the fact that you're able to say this much about the tenant
>>>> concept and SSE in this reply speaks a great deal to how these are
>>>> relatively complex topics that warrant their own discussion. I'm not
>>>> comfortable adopting this draft wholesale, because I don't think this draft
>>>> is necessarily the right layer to introduce these concepts to OpenID
>>>> Connect.
>>>>
>>>> The tenant problem is a great example as you mentioned, since Google
>>>> and Microsoft both have different ways they handle the tenant concept. This
>>>> should ultimately be standardized in OpenID Connect Core so that there is a
>>>> standard way to include the tenant in ID tokens regardless of whether the
>>>> OP is using OP Commands.
>>>>
>>>> I am still not convinced that SSE is actually an easier alternative to
>>>> pagination compared to what is being done in SCIM. I suspect there are also
>>>> plenty of edge/error cases that will come up with SSE as a syncing
>>>> mechanism that will require their own creative solutions down the road. Yes
>>>> there are currently server-side client libraries of SSE, but they are not
>>>> necessarily being used for data synchronization the way SSE is applied
>>>> here. Plus, as you mentioned, SSE is used for the tenant audit which is for
>>>> brownfield implementations, so it's entirely possible an implementation
>>>> would never need to build this, which suggests this would be better as a
>>>> separate draft as well.
>>>>
>>>> Yes, having separate drafts can make things more complex for readers in
>>>> the short term. But OAuth 2.1 brings together a carefully selected set of
>>>> drafts from the past 12 years of OAuth. If OAuth had been created all as a
>>>> massive single draft at the beginning, it would be even more of a mess than
>>>> it is today. So I don't think putting these three new concepts into a
>>>> single new OpenID draft is a good path forward.
>>>>
>>>> Aaron
>>>>
>>>>
>>>> On Fri, Feb 21, 2025 at 1:14 PM Dick Hardt <dick.hardt at gmail.com>
>>>> wrote:
>>>>
>>>>> Hey Aaron, thanks for the feedback.
>>>>>
>>>>> I think these are important points to discuss, but that I would prefer
>>>>> to have the discussion once the WG has decided to adopt the draft so that
>>>>> we can capture all the discussion in the repo rather than this list so that
>>>>> it is easier for others to find the discussion.
>>>>>
>>>>> With that being said, and knowing that I will need to copy this
>>>>> content into the repo later on, here is why I think we want to keep tenant
>>>>> and SSE concepts in the draft:
>>>>>
>>>>> *tenant*
>>>>>
>>>>> The tenant concept is threaded through all of the draft, not just the
>>>>> tenant commands. The "tenant" claim is required in all of the commands.
>>>>> While the tenant concept has not been standardized in OpenID, Google
>>>>> includes a tenant claim "hd" in Google Workspace ID Tokens, and Microsoft
>>>>> includes "tid" in their ID Tokens. Microsoft has a unique issuer for each
>>>>> tenant, but Google does not. In order for Google to adopt OP Commands, we
>>>>> need to provide a standard tenant mechanism, otherwise they will need to
>>>>> add a non-standard claim to their commands to communicate with the tenant.
>>>>> I would like to keep the barrier to adoption by Google as low as possible,
>>>>> and for RP libraries not to have custom code to support Google.
>>>>>
>>>>> The tenant commands include the tenant_metadata, the only command that
>>>>> an RP MUST implement. The tenant_audit command is needed for brown field
>>>>> adoption for the RP to add OP Commands, and an OP to understand the current
>>>>> state. IE, the OP needs it to get the starting state when OP Commands are
>>>>> enabled. A brand new RP could decide to not support tenant_audit for
>>>>> simplicity, but not having tenant_audit would be a barrier for adoption for
>>>>> some existing RP / OP deployments.
>>>>>
>>>>> The other commands are tenant wide versions of the other commands. An
>>>>> RP can choose to not support them. I did notice in the OpenID Slack
>>>>> wg-sharedsignals that someone wanted to know how to send a signal for a
>>>>> tenant, and it was suggested the set the subject to:
>>>>>
>>>>>
>>>>> {
>>>>>   "format": "complex",
>>>>>   "tenant": "tenant-whose-users-were-revoked"
>>>>> }
>>>>>
>>>>>
>>>>> I agree that the tenant claim is not OP Commands specific, and that it
>>>>> may make sense to have a separate document for it, and If the WG wants to
>>>>> specify the tenant claim as a separate document, I'm fine with that, but I
>>>>> strongly believe the tenant claim needs to be used in OP Commands, and so
>>>>> we should adopt the document as is and then we can decide if we want to
>>>>> separate them out or not, as the tenant claim doc would need to exist for
>>>>> it to be used by OP Commands.
>>>>>
>>>>> Per the motivation to create OAuth 2.1, I also think having a large
>>>>> number of documents makes it harder for people to grasp everything, so I
>>>>> would argue that perhaps OP Commands introduces the tenant claim and gets
>>>>> it registered in IANA. Note that OP Commands is also defining the group
>>>>> claim, which is currently underspecified.
>>>>>
>>>>> *SSE*
>>>>>
>>>>> You are correct that using SSE between servers is a non-traditional
>>>>> use of SSE, and that client libraries are not as abundant as server
>>>>> libraries for SSE. The fact that there are client libraries indicates that
>>>>> there are server implementations. Also it is the OP that is the client
>>>>> here, which is the party where we want to push complexity, and server
>>>>> libraries are readily available for an RP to use.
>>>>>
>>>>> I think it adds complexity long term to have more than one way for the
>>>>> RP to send a response, and given that SSE is pretty straightforward and
>>>>> addresses one of the complexity challenges in SCIM (pagination) we should
>>>>> keep it in the draft so that we are forced to address how the RP will send
>>>>> a large response back to the OP in an audit. While we might not decide on
>>>>> SSE -- we don't want to punt on a mechanism for working at scale.
>>>>>
>>>>> From an implementation point of view, simple, new RPs don't need SSE
>>>>> if they don't need to support any tenant commands other than
>>>>> tenant_metadata, which is required.
>>>>>
>>>>> /Dick
>>>>>
>>>>> On Fri, Feb 21, 2025 at 4:56 PM Aaron Parecki via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>>> I took another look at the draft after the discussion on the last
>>>>>> call, and I have concerns about the current state of the document and think
>>>>>> it should be revised before adopting it. I realize changes are possible
>>>>>> after adoption, but I believe the scope of the current document is too
>>>>>> broad, and should be narrowed before adoption.
>>>>>>
>>>>>> In general I am supportive of a lighter weight way to achieve most of
>>>>>> what is described in this draft. I like that the command tokens leverage
>>>>>> the existing signing key that RPs already use to validate ID tokens. The
>>>>>> account lifecycle commands are well thought out and I appreciate the state
>>>>>> transition diagram in the draft.
>>>>>>
>>>>>> However, I have concerns about the Tenant commands as well as the use
>>>>>> of Server-Sent Events.
>>>>>>
>>>>>> The Tenant commands bring in a new concept that does not exist
>>>>>> elsewhere in OpenID Connect today. I understand the goal here, but I am not
>>>>>> convinced this draft is the right place to introduce this concept. This
>>>>>> would be better off as a separate OpenID Connect extension that extends
>>>>>> both OpenID Connect Core and OP Commands to add the Tenant concept.
>>>>>>
>>>>>> The use of Server-Sent Events is somewhat unusual here. It
>>>>>> technically works, but the API is actually defined in HTML as an API to
>>>>>> allow a web server to stream content to a web browser. I am personally a
>>>>>> huge fan of SSE as it's easier to deploy in web servers compared to
>>>>>> Websockets. Using it for server-to-server communications is a somewhat
>>>>>> non-traditional application of the technology. While it would work, I am
>>>>>> concerned that it is not the best tool for the job, since there are far
>>>>>> fewer server-side SSE client libraries since most of the use is where the
>>>>>> client is the web browser. That said, I am not entirely opposed to using it
>>>>>> this way, I just worry that bringing it in to the OP Commands draft this
>>>>>> early might backfire on the other more easily understood patterns in the
>>>>>> draft.
>>>>>>
>>>>>> This is all to say that I would support adopting a version of this
>>>>>> draft that describes only the account lifecycle commands with HTTP delivery
>>>>>> as described in the first half of the document, and remove the Tenant
>>>>>> commands and SSE delivery mechanisms.
>>>>>>
>>>>>> Aaron
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>> _______________________________________________
>> 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/20250305/8db0a967/attachment-0001.htm>

More information about the Openid-specs-ab mailing list