[Openid-specs-ab] Review of OpenID Provider Commands (draft 00)

Wed Mar 12 22:53:10 UTC 2025

On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com> wrote:

>
>
> On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com>
> wrote:
>
>> Hi WG,
>>
>> Wanted to send some feedback and suggestions a bit earlier... but didn't
>> have enough time for that.
>>
>> 1. I suggest extending Section 4 (Command Token) with a new required
>> claim (client_id) to help prevent and address potential misuse and abuse.
>> Thus, one of the provided examples for the command token (activate) becomes
>> to look like this
>>
>> *{*
>> *  "iss": "https://op.example.org <https://op.example.org>",*
>> *  "sub": "248289761001",*
>> *  "aud": "https://rp.example.org <https://rp.example.org>",*
>> *  "client_id": "client1234567890"*
>> *  "iat": 1734003000,*
>> *  "exp": 1734003060,*
>> *  "jti": "bWJq",*
>> *  "command": "activate",*
>> *  "given_name": "Jane",*
>> *  "family_name": "Smith",*
>> *  "email": "jane.smith at example.org <jane.smith at example.org>",*
>> *  "email_verified": true,*
>> *  "tenant": "ff6e7c9",*
>> *  "groups": [*
>> *    "b0f4861d",*
>> *    "88799417"*
>> *  ]*
>> *}*
>>
>>
>> The key idea is that the aud claim includes (one or more) RP URLs where
>> the client_id claim "carries" the client identifier. Note, this is in line
>> with JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)
>> <https://datatracker.ietf.org/doc/html/rfc9068>.
>>
>
> I'd prefer clarifying that the `aud` is the `client_id`, and has a single
> value. Is there a motivation for having the `aud` and `client_id` be
> different?
>

Once you put "client_id" in the aud claim, you became a vulnerable for
confusion attacks for those OPs (and authorization servers) that
allow clients to influence their client_ids, I didn't make this up, this is
part of the Best Current Practice for OAuth 2.0 Security (RFC 9700)
<https://datatracker.ietf.org/doc/html/rfc9700>, what I did is
"simply" applied this to OP Commands.

>
>
>>
>> 2. An OP should be able to encrypt OP Commands using encryption keys(s)
>> when they are available in the Client's Metadata.
>> <https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata>
>>
>
> Why would that be useful? It might not be currently specified, but the
> commands_uri MUST be HTTPS, so secrecy is provided between OP and RP.
>

These days, you typically don't get an end-to-end TLS session between the
involved parties, there are all sorts of intermediaries that perform TLS
offloading, deep packet inspection (DPI) and whatnot. But, I can also turn
your question around - why does OpenID Connect Core spec allow encrypting
its ID Tokens?

>
>
>>
>>
>> 3. I suggested enabling nested groups in section "6.1 Metadata Command".
>> Are there particular reasons for having and allowing only a plain
>> structure? That shouldn't be a big issue to remove this limitation in the
>> way I see it. Nested groups offer convenience and simplify their and
>> permission management.
>>
>
> Would you elaborate on how this would work? What would it mean if a group
> was in a group for a user? While groups can be made up of groups when
> defining a group, the account either belongs to a group or not.
>

First of all, RPs can make use of the structure of groups (how they are
nested in each other) alone, I'd even say that in some cases, it's very
desirable to have this piece of information. Secondly, you don't need to
indicate in OP Commands such as "activate" that user1 is a member of
group1.1 when this group is included in group1.

>> 4. I don't think I clearly understand what's the goal of claim "domains"
>> in section "6.1 Metadata Command". If they are vendor specific, I'd suggest
>> removing them from the spec altogether. It shouldn't be an issue to add
>> them, as well as other claims, if a particular implementation / vendor
>> needs them.
>>
>
> These are DNS domains controlled by the tenant, and are a common way for
> an RP to determine if accounts belong to the same organization.
>

What you described seems to be vendor specific details. I never said they
aren't needed, these details simply don't necessarily need to be part of
the spec.

>
>>
>> 5. I suggest using the claim "member_of" instead of "group" in OP
>> Commands such as the activate command.
>>
>
> Why?
>

I'd say it's because of all my prior LDAP experience (specifically MS
flavor of it), I'd love to hear other opinions from the WG.

>
>
>>
>> 6. I find it a bit odd how an OP retrieves the metadata from an RP. For
>> that it needs to push its metadata first (using the POST HTTP Method) and
>> then it retrieves the Metadata Response (Section 6.2). I would like to have
>> more clarification on this matter (yes, I know this is the very first
>> draft).
>>
>
> Part of the OP metadata that the RP requires to respond is the OP tenant
> for the Command as the RP may provide different metadata for different
> tenants.
>
> The OP metadata may also provide different metadata for different RPs (as
> identified by aud). Passing the OP metadata to the RP and then the RP
> responding with its metadata seemed efficient.
>
> The groups metadata claim enables the id and display of a group to be
> provided once. This allows the groups claim to be an array of identifiers
> rather than the SCIM approach where it is an array of objects with
> redundant data.
>
>
>
>>
>> 7. It would be great to know if there is any interest to have partial
>> upgrades of the RP Metadata using  JSON Merge Patch (RFC 7386). That would
>> be very convenient in some cases, for instance, an OP just wants to add and
>> remove a few groups, etc.
>>
>
> It would be great to know!
>
> Currently the spec strives for simplicity and full transfers in the
> metadata, as well as in the tenant_audit response, and in the activate and
> maintain commands. We are trading simpler code paths for using more
> bandwidth.
>

I'd love to hear other opinions from the WG on that.

>
> If there are a massive number of groups, SCIM is likely a better protocol
> as it allows direct management of groups as a resource, where OP commands
> only manages accounts, and groups is a claim about the account.
>
>
>
>
>>
>> All the best,
>> Andrii
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250312/9c1b5095/attachment.htm>