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

[Dick Hardt]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250221/5087eedc/attachment-0001.htm>