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

Fri Feb 21 09:30:26 UTC 2025

Thanks for the additional feedback Andrii. I see that you were on the
Tuesday call -- I'll try to make the next Tuesday call to provide
additional clarification ... response inline until then ...

On Fri, Feb 21, 2025 at 12:43 AM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> 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
> .
>

Correct. No magic here!

>
> 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.
>

I agree that there is no discussion or guidance on sending simultaneous
commands. I appreciate the call out!

While nothing prevents an OP from sending simultaneous commands -- we do
want to consider the compute capacity of the RP and not overwhelm it. Hence
the suggestion of the RP being able to specify how many simultaneous
commands / connections it can support.

I'm not clear on your question though. An activate command is for a single
account and has a single JSON response. The tenant_audit command is for the
entire tenant and is a streaming response containing one or more JSON
events.

>
> 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 tenant concept also enables a single tenant OP to indicate if it is
supporting consumer / personal accounts or an organization account.

>
> 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.
>

Yeah!

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

Appreciated!

>
> 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_-2588742849153675510_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_-2588742849153675510_m_289164681928415475_m_171905812464025218_m_6654295499515395842_m_-6800859992948440431_section-1-1.3>
>>>>>
>>>>> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
>>>>> <#m_-2588742849153675510_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_-2588742849153675510_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_-2588742849153675510_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_-2588742849153675510_m_289164681928415475_m_171905812464025218_m_6654295499515395842_m_-6800859992948440431_section-1-1.7>
>>>>>
>>>>> *4. Why are there only groups? Why not roles and entitlements?*
>>>>> <#m_-2588742849153675510_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/20250221/3d4c50df/attachment-0001.htm>