There are more points of discussion to take into account:

1. in the previous MitreID dashboard an IAM user could access to a limited view of client details using the client_id and the Registration Access Token (RAT) IAM issued during client registration (and never shown again). We have found it very confusing for an average user, due to the introduction of new token unrelated to our JWTs, so when moving the client's dashboard to the IAM one we have automatically assigned the ownership to the authenticated user who registered the client. A limitation for the current strategy is for unauthenticated registered clients, as oidc-agent one: in this case, IAM offers a way to assign ownership (click on Redeem button) by filling the form with client_id and RAT. Previous oidc-agent versions were showning an orange-coloured JSON of the IAM response after client registration, containing also the RAT. This response is no longer supported and we are wondering if it is better to ask oidc-agent team to introduce it again (such that users will obtain ownership through client_id and RAT), or go on thinking about the best option on IAM side

2. when one registers an oidc-agent client with oidc-gen ... the user is not asked to login in order to register the client; it is asked to login in order to give the consent to that client during an OAuth authorization/device code flow. This creates quite often some confusion about the expectations of "owning a client", because the use of oidc-agent for a "personal client" has somewhat collapsed the concepts of client owner and client user -- to be redundant, the oidc-agent registration into IAM is dynamic and anonymous

3. for an already registered oidc-agent client, one can enforce the client to ask the consent again calling oidc-gen -m .... Thus, the new token obtained with oidc-token ... will have as subject the last user who gave grant, which is not neccessarily the one who issued the first oidc-gen command

4. to give an operator who has to debug oidc-agent related issues (for istance) the device code generated during the OAuth device code flow would help in debugging, without any need to share oidc-agent secrets. In this case the oidc-agent client would appear also in the My clients tab of the operator -- is this fine?

5. or, we could assign client ownership to the last person who gave grant to the client. Only Admins can assign shared client ownerships

4. to give an operator who has to debug oidc-agent related issues (for istance) the device code generated during the OAuth device code flow would help in debugging, without any need to share oidc-agent secrets. In this case the oidc-agent client would appear also in the _My clients_ tab of the operator -- is this fine?

I would say that the owner is the operator, even if the subject is of another user. In other words, the owner is the one with the RAT (assuming that we can get it again from oidc-agent during client registration).

In fact, the operator doesn't even need to be part of the organization...

5. or, we could assign client ownership to the last person who gave grant to the client. Only Admins can assign shared client ownerships

I would say the owner is the one who registers and has the RAT, unless the RAT is passed to someone else which can redeem (but I would rename it to "reclaim") the ownership.

F.

Is there an use-case where dynamic anonymous registration is useful on the production IAM instances? Applications that register new clients should first login. It seems to me a bit weird that anonymous can create client / database entry - what happens if some bad person decides to do millions of registration?

Client ownership can be dangerous in some cases, e.g. if IAM Admin assign to the client some restricted scopes and owner can than add client_credential grant type to avoid scope policies that are applied only to the refresh token flow.

Is there an use-case where dynamic anonymous registration is useful on the production IAM instances?

All oidc-agent clients are dynamically and anonymously registered (for ATLAS it's 118 out of 175, for example). The subsequent consent requires authentication.

Applications that register new clients should first login. It seems to me a bit weird that anonymous can create client / database entry - what happens if some bad person decides to do millions of registration?

Denial of service. But there are easier ways to mount a denial of service attack.

Client ownership can be dangerous in some cases, e.g. if IAM Admin assign to the client some restricted scopes and owner can than add client_credential grant type to avoid scope policies that are applied only to the refresh token flow.

It all depends on what a client owner can do. There is non such role at the moment (in practice).

Is there an use-case where dynamic anonymous registration is useful on the production IAM instances?

All oidc-agent clients are dynamically and anonymously registered (for ATLAS it's 118 out of 175, for example). The subsequent consent requires authentication.

I guess this is just a side effect that oidc-agent doesn't support something better... should not we just ask developers of this tool to improve supported registration methods?

I guess this is just a side effect that oidc-agent doesn't support something better... should not we just ask developers of this tool to improve supported registration methods?

Sure. Token usability is not great at the moment.

Partially related to issue #595.

PR #817.

At least in IAM 1.9.0 owner is still able to add client_credential grant type even for clients with restricted scopes. With client credential flow IAM doesn't check scope policies and e.g. client that have restricted scope storage.modify:/ which is further restricted by scope policies to storage.modify:/testarea can gain privileges with client_credential to get directly token with storage.modify:/ (that leads me to question if same "privilege escalation" would be possible even with current IAM version if user knows registration access token and push "Redeem client" button).

May be this is not really issue if IAM administrators knows that they should never add restricted scope to the client owned by user or client where user have access to registration token. Basically, IAM administrators should know that restricted scopes can be safely added only to the clients they created and they did not set its owner to the user ... is this assumption about IAM admin knowledge safe or dangerous?

Hi Petr, since client_credential flow is gaining more power (as you say it is not filtered by policies and so on) we are thinking about it as an authorization grant that excludes all other grants for the same client, i.e. there is no possibility to add more grants for the same client if client_credentials is one of them. I think this should solve also your use-case, isn't it? If we want to keep discussing this functionality I would open a separate issue.