[Openid-specs-ab] Call for Adoption of the OpenID Connect Enterprise Extensions Specification

[Andrii Deinega]

 I support the adoption of this specification for one single reason: it
lets us agree on what goes in an ID Token and in an OP Command to
distinguish one OP tenant from another. This scenario is mostly applicable
and needed in one particular context - when an OP “uses” the same issuer
for all its tenants. There are many multi-tenant OPs that aren't "affected"
by that, in other words, their tenants have their own issuers (this
architecture should be encouraged as a best practice in my view).

A few other comments

My recommendation would be to be flexible enough to express not only a
single OP tenant, but also a subtenant in it when it's needed, and so
forth. The tenant claim as a JSON string with an opaque value in it alone
might not be a good fit for this. I think it's safe to say that use cases
involving sub tenants are quite common for various B2B authN scenarios.

The second comment is all about values “personal” and “organization” in the
tenant claim, they should be separated from this claim. Otherwise, there is
too much room for abuse, to illustrate this, an ID Token (sub:12345 and
tenant:personal) issued by an OP with the same issuer means different
things for its tenant A (Org A) and tenant B (Org B). If I didn't get this
part right from section
<https://dickhardt.github.io/enterprise-extensions/openid-connect-enterprise-extensions.html#section-2.2>

The tenant claim is an opaque JSON string that represents a tenant
> identifier and MAY have the value personal, organization or a stable OP
> unique value for multi-tenant OPs. The personal value is reserved for when
> Accounts are managed by individuals. The organization value is reserved for
> Accounts managed by an organization.


it needs to be rephrased and clarified.

All the best,
Andrii

On Thu, May 22, 2025 at 4:37 PM Dick Hardt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> +1 as an author :)
>
> For those not familiar, some of these extensions are based on requirements
> from IPSIE. If adopted, the 'tenant' text in OpenID Provider Commands would
> point to this document.
>
> On Thu, May 22, 2025 at 3:21 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
>> Connect Enterprise Extensions specification contributed to the working
>> group by Dick Hardt and Karl McGuiness as an OpenID Connect Working Group
>> specification.  Please reply-all by Thursday, June 5th saying whether
>> you are favor of adoption or not, briefly also saying why.
>>
>>
>>
>> For additional information, the specification repository is
>> https://github.com/dickhardt/enterprise-extensions.
>>
>>
>>
>>                                          Writing as a working group chair,
>>
>>                                                        -- Mike
>>
>>
>>
>> _______________________________________________
>> 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/20250523/954b288b/attachment.htm>