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

[Dick Hardt]

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?


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


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


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


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

Why?


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

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/77c881ca/attachment-0001.htm>