[Openid-specs-ab] OpenID Provider Commands - proposed WG specification
Vladimir Dzhuvinov / Connect2id
vladimir at connect2id.com
Thu Jan 30 13:03:22 UTC 2025
Hi Dick,
On 23/01/2025 16:52, Dick Hardt wrote:
> Hi Vladimir
>
> By "enterprise app" are you referring to internal apps, or a B2B SaaS
> app? Internal apps can have direct access to the directory in many
> cases, so I'm assuming you are referring to B2B SaaS apps.
Both actually. In those cases when we dealt with internal apps to be
integrated via OIDC, the aim was to regulate access to the user data via
the OpenID provider, and close off LDAP access.
What I like about the "Commands" is that it may simplify the necessary
dealings for apps to be GDPR compliant. Managing that via the OIDC layer
looks appealing.
> In my experience, an app needs to have a robust DB of user data. The
> OP knows when the data changes, so can push to the RP whenever there
> is a change, To ensure there the data is in sync in case a command was
> missed or something, the OP occasionally can send a tenant_audit
> command to ensure the RP has what the OP thinks it should have.
The task to supply user data in an app, in a persistent and
well-structured fashion, looks easier when that's built on top of a
RESTful resource. Rather than on incoming RPC. App developers are more
comfortable with RESTful resources and there is more available software
to deal with that.
An OP resource for the accounts and tenants will not make the JWTs to
notify of state changes redundant. They'd still be useful to tell the RP
to update its state.
Vladimir
>
>
> On Thu, Jan 23, 2025 at 8:43 AM Vladimir Dzhuvinov / Connect2id via
> Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>
> Hi Dick, hi Aaron,
>
> If I were an enterprise app developer, having an "account" and
> "tenant" resource hosted and managed for me by the OP would seem
> like a great convenience. I'd be able to cache the account and
> tenant data in my app, but that would not be so critical (as when
> data is received via commands), because whenever I need to, I'd be
> able to call upon an authoritative resource at the OP. If my app
> misses a command, that would seem to be less of an issue. A simple
> GET of the OP resource would always give me the correct current
> state and account data.
>
> Aaron, yes, an OP resource would require an access token. I
> haven't thought through that. Could the signed JWT for the state
> change be used as some form of authorisation?
>
> The "account" and "tenant" data look similar to the UserInfo
> resource we currently have in OIDC. With an added crucial feature,
> to communicate state changes from OP to RP.
>
> Vladimir
>
> On 16/01/2025 19:50, Dick Hardt via Openid-specs-ab wrote:
>> Adding to Aaron's comments.
>>
>> The account and tenant information is all managed by the OP, and
>> the OP knows when it changes, so the OP knows when to push the
>> changes to the RP. Telling the RP to pull the data seems
>> inefficient, and this approach allows the RP to be passive and
>> receive data when it changes.
>>
>> But perhaps I am missing something in our suggestions. Can you
>> elaborate on why you are suggesting that and what the advantages
>> might be?
>>
>> Related: Karl and I have pondered how can the RP tell the OP it
>> wants the metadata again. One approach would be the OP provides
>> that functionality in its RP management console.
>>
>>
>> On Thu, Jan 16, 2025 at 2:27 PM Aaron Parecki via Openid-specs-ab
>> <openid-specs-ab at lists.openid.net> wrote:
>>
>> Vladimir, I understand the thought behind this suggestion,
>> but I think it only adds unnecessary complexity.
>>
>> The value of this draft comes from leveraging the existing
>> relationship and configuration between the RP and IdP, namely
>> that the RP is necessarily already configured to validate
>> signed ID tokens, and this draft builds on that to send
>> signed tokens with the same signing key so that there isn't
>> another credential to configure and maintain.
>>
>> Alternatively, making the RP fetch the data means forcing the
>> RP to maintain an access token, defining an API request and
>> response vocabulary, defining endpoint discovery for the API,
>> etc, much more work on both ends for little benefit.
>>
>> Aaron
>>
>>
>>
>> On Thu, Jan 16, 2025 at 4:00 AM Vladimir Dzhuvinov /
>> Connect2id via Openid-specs-ab
>> <openid-specs-ab at lists.openid.net> wrote:
>>
>> Dick, Karl, hi.
>>
>> Interesting draft.
>>
>> I'm wondering whether the messaging and the overall
>> architecture could be simplified by sending simple "state
>> changed" JWTs from OP to RP. Instead of "command+data" JWTs.
>>
>> * The "account" and "tenant" are protected resources at
>> the OP.
>>
>> * The "account" and "tenant" resources have a clearly
>> designated current state / status, e.g. "active".
>>
>> * If the state changes the OP sends a "state changed" JWT.
>>
>> * The RP can always check / poll the resource (for
>> changes, or if it suspects a missed JWT). Cache
>> headers could be used to hint when to recheck.
>>
>> * The resource may provide a history of the changes.
>>
>> *
>>
>>
>>
>> Vladimir Dzhuvinov
>>
>> On 15/01/2025 14:29, Dick Hardt via Openid-specs-ab 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?*
>>>
>>> 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
> _______________________________________________
> 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/20250130/0de909c1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4264 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250130/0de909c1/attachment-0001.p7s>
More information about the Openid-specs-ab
mailing list