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

Fri Feb 21 00:42:48 UTC 2025

There is no magic behind SSE, I think everything is pretty straightforward
with it per https://html.spec.whatwg.org/multipage/server-sent-events.html.

I wanted only to highlight that this very first version of the spec
(draft-00) doesn't clarify (at least for me) if it's possible to send two,
or more OP Commands at the same time, say activate (or audit) accountA and
accountB requesting Streaming Response for them. It's very possible that
this wasn't ever intended to be supported.

While I agree with everything you said about large multi-tenant OPs, I
don't think that is general, an OP is an entity that decides when an RP
needs to deactivate a tenant (suspend_tenant, delete_tenant, etc.).

The only one that I expect to get widely implemented would be tenant_audit
> -- and I suspect most RPs will not do that initially.

That's great, it explains.

Overall, again, I like and support the whole idea. "I will be leaving minor
nitpicks here and there for the feature revisions.

All the best,
Andrii

On Mon, Feb 17, 2025 at 2:36 PM Dick Hardt <dick.hardt at gmail.com> wrote:

>
>
> *SSE *
> Perhaps you don't understand how SSE works?
>
> The OP sends a Command that has a streaming response. This MUST be an HTTP
> 1.1 request, and MUST have the header Accept text/event-stream.
>
> See
> https://dickhardt.github.io/openid-provider-commands/openid-provider-commands-1_0-00.html#name-streaming-request
>
> The RP then sends events in response until it has completed sending
> its response, and then the connection is closed.
>
> No connection is left open. The RP does not send anything until it
> receives the Command.
>
> Yes, I briefly considered wss:. Holding open a connection with wss: would
> be a waste of resources for most OP <> RP connections.
>
> I've implemented and deployed SSE numerous times. While that was always
> with a browser as the client, it was really simple on the server to send
> events, which is what the RP is doing.
>
> *Tenant Support*
>
> Not sure what you mean by tenant management. Most large OPs (eg. Google)
> are multi-tenant OPs that use the same issuer for all tenants, and need to
> signal which tenant a command is in reference to.
>
> As an RP, you would need to know which tenant is being referenced.
>
> If you are concerned about all the Tenant commands. Note they are all
> optional. The only one that I expect to get widely implemented would be
> tenant_audit -- and I suspect most RPs will not do that initially.
>
> An RP implementing the metadata, activate, delete, and unauthorize
> commands covers most requirements for lifecycle management. Add in
> tenant_audit to deal with entropy, and there is not much more needed. But
> some people will want more, so I included the full ISO lifecycle, and the
> tenant wide commands so people that wanted them did not need to make things
> up.
>
> /Dick
>
>
>
> On Mon, Feb 17, 2025 at 9:49 PM Andrii Deinega <andrii.deinega at gmail.com>
> wrote:
>
>> > Am I missing something? What do you think?
>>
>> Dick, yes, an OP will need to establish and maintain one connection to
>> subscribe to updates from an RP, plus another one (or even more) to send to
>> OP Commands. The RP will also need to understand when it has responded to
>> all OP Commands within this SSE connection so then it can "safely" close
>> it. There are also other minor things / considerations...
>>
>> HTTP 2 will definitely make it a bit less cumbersome (there will be only
>> one connection), but HTTP 2, or HTTP 3 doesn't come for free from an Infra
>> standpoint.
>>
>> This all is doable...but are there any better options?
>>
>> Tell me this... have you considered using wss:// instead (Secure
>> WebSocket)? That could have several benefits; we deal with bidirectional
>> communication channels, an RP doesn't need to be reachable for an OP, etc.
>> As a side note, I chatted with Atul about this for Shared Events but so
>> far, that didn't take off.
>>
>> Another thing I would like to mention, I'd much rather prefer to not see
>> anything about tenant mngt in the spec, this is my opinion. If you like to
>> cover that for your needs, then it can be easily done in extensions (I
>> refer to "Defining New Commands", or alternatively, information about
>> tenants can be passed as option / custom attributes for accounts / groups,
>> etc.).
>>
>> I really like Michael Schwartz's suggestion to publish Token Status
>> Lists! OAuth Authorization Servers and RSs can avail your Commands as well.
>>
>> Lastly, this idea also somewhat overlaps with
>> https://openid.net/specs/openid-connect-prompt-create-1_0.html from
>> George.
>>
>> All the best,
>> Andrii
>>
>>
>> On Mon, Feb 17, 2025 at 5:14 AM Dick Hardt via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> 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_289164681928415475_m_171905812464025218_m_6654295499515395842_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_289164681928415475_m_171905812464025218_m_6654295499515395842_m_-6800859992948440431_section-1-1.3>
>>>>
>>>> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
>>>> <#m_289164681928415475_m_171905812464025218_m_6654295499515395842_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_289164681928415475_m_171905812464025218_m_6654295499515395842_m_-6800859992948440431_section-1-1.5>
>>>>
>>>> *3. Are OpenID Provider Commands a replacement for SCIM, Shared
>>>> Signals, or RISC?*
>>>> <#m_289164681928415475_m_171905812464025218_m_6654295499515395842_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_289164681928415475_m_171905812464025218_m_6654295499515395842_m_-6800859992948440431_section-1-1.7>
>>>>
>>>> *4. Why are there only groups? Why not roles and entitlements?*
>>>> <#m_289164681928415475_m_171905812464025218_m_6654295499515395842_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.
>>>>
>>>> _______________________________________________
>>> 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/20250220/b084c302/attachment.htm>