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

[Andrii Deinega]

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

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>

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.

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.

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

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

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.

All the best,
Andrii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250312/95df9c9a/attachment.htm>