V51 - Requirements for dynamic client registration

[randomstuff]

We currently don't have anything to say about dynamic client registration. Should this be covered somehow?

Suggestions:

Verify that if the client supports dynamic client registration on unknown authorization servers, it mitigates the risk of malicious authorization server. It MUST ensure the user's consent and warn the user before initiating an authorization request with an untrusted authorization server.

Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It MUST ensure the user's consent and warn the user before processing an authorization request with an untrusted client application.

[elarlang]

@randomstuff - note that the first proposed requirement seems unfiinishsed.

[randomstuff]

Fixed :)

[TobiasAhnoff]

A suggestion is to add "metadata validation" to the second requirement, like this

Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It MUST validate client metadata such as any registered URIs, ensure the user's consent and warn the user before processing an authorization request with an untrusted client application.

[randomstuff]

Ne proposition for the first one:

Verify that if the client supports dynamic client registration to dynamically discovered authorization servers, it mitigates the risk of interacting with malicious authorization servers. The authorization server client MUST ensure the user's consent and warn the user before initiating an authorization request with such authorization server not known to be trusted by the user.

"dynamically discovered" is not so great. I mean that the authorization server is provisioned by the user, or by the interaction with some resource server as opposed to already known in configuration / provisioned by the admin.

Maybe this is better (?):

Verify that if the client supports dynamic client registration to dynamically registered authorization servers, it mitigates the risk of interacting with malicious authorization servers. The authorization server client MUST ensure the user's consent and warn the user before initiating an authorization request with such authorization server not known to be trusted by the user.

" dynamic client registration to dynamically registered authorization servers" seems somewhat weird.

Edit: I messed up my copy/paste when making editing the requirements 😄 fixed "authorization server" → "client"

[elarlang]

Verify that if the client supports dynamic client registration

This feels like a loop.

[randomstuff]

This feels like a loop.

Yes, the wording is quite redundant 😄. The intent was to make clear that we are talking about "OAuth dynamic client registration" (the protocol).

But actually, this would apply even if a custom/different client registration protocol was used so we can probably simplify to: "Verify that if the client supports registration to dynamically registered authorization servers"

[randomstuff]

This requirement is related (and possibly somewhat redundant) to:

50.8.1 [ADDED, SPLIT FROM 5.1.5] Verify that the application shows a notification when the user is being redirected to a URL outside of the application's control, with an option to cancel the navigation.

[TobiasAhnoff]

This requirement is related (and possibly somewhat redundant)

Yes, they seem redundant, 50.8.1 could also be written in the same language as purposed here (but without OAuth terms), perhaps like this

Verify that if the client application supports redirection to servers outside of the application's control (not known to be trusted by the user), it mitigates the risk of interacting with malicious servers. The client MUST warn or notify, with an option to cancel the navigation, before initiating the request with such a server.

I suggest to only have 50.8.1 (perhaps updated with text suggested here, if so, open an issue for that) and one new requirement for dynamic client registration

Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It MUST validate client metadata such as any registered URIs, ensure the user's consent and warn the user before processing an authorization request with an untrusted client application.

[randomstuff]

@TobiasAhnoff, that makes sens to only have 50.8.1. In this case, shall we include a note in the OAuth chapter referencing to 50.8.1? Something like:

See as well 50.8.1: it applies to client applications redirecting to untrusted authorization servers.

[TobiasAhnoff]

shall we include a note?

Yes, I think it would be good to note in chapter/section text for the OAuth chapter

[elarlang]

I think the context for the requirements are quite different and I don't see them as clear duplicates. Or I miss something here?

[randomstuff]

@elarlang, if 50.8.1 is reformulate like #2427 (comment), it could subsume the first proposed requirement.

I am not sure if it is better to do that or to include the proposed requirement, however.