Messages - 2.1.2.1 Overlay client request registration over the authentication request

[Nat Sakimura]

Esp. for self-issued IdP, separate registration step is a nuisance.

RP will never know whether it has registered or not to the custom scheme IdP, and invoking App for registration everytime is a bad user interaction.

Proposal: add registration JSON to the request object.

{{{ “registration”: { ? “claims”: { ? “redirect_uris”: “https://rp.com/authz/callback”,? ? “logo_url”: “https://rp.com/logo.png”, ? “jwk_url”=“https://rp.com/public_key.jwk”,? ? “userinfo_encrypted_response_algs”: “RSA1_5 A128CBC” ? }? }

}}}

[Michael Jones]

I don't think the "claims" structure level is needed. Redirect_uri isn't needed because it's an OAuth parameter. The values of the "registration" entry would be registration parameters that make sense in the context - for instance, logo_url, encryption parameters for the id_token, if applicable, etc. There is no basis for validating the logo_url.

John points out that this could make self-issued more different than the normal flow. Nat responds that not being able to do this is a user interface nightmare.

The alternative to doing this is to bring back dynamic encryption request parameters to the request object. This might make better sense than adding registration information to the request object. Nat plans to write up a separate proposal to do this and then close this bug on that basis.

[Nat Sakimura]

Just to capture the conversation:

Some of the variables listed above does not make sense to be used as "registration" values.

• “redirect_uris”: This can be sent as the top-level request object parameter already.
• “logo_url”: There is no way to verify this logo.

[Nat Sakimura]

If we take the comment on "logo_url" as above, then we probably need to drop it from openid-connect-tregistration-1_0.

[Nat Sakimura]

What about:

RP can always send in the registration request.

If it was already registered, then it will be ignored. Trust On First Use (TOFU).

Every claims in the client registration spec can be sent.

If client_update probably should not be supported... needs more consideration.

	“registration”: {
			“redirect_uris”: “https://rp.com/authz/callback”,
			“logo_url”: “https://rp.com/logo.png”,
			“jwk_url”=“https://rp.com/public_key.jwk”,
			“userinfo_encrypted_response_algs”: “RSA1_5 A128CBC”
 		}

[Michael Jones]

The working group requests that Nat produce a specific proposal of what would be added and add it as a comment on this issue.

[Nat Sakimura]

Pending the self-issued document.

Possible to add the following text after the explanation of id_token.

registration
OPTIONAL: Requests the client to be to be registered at the authorization server for the self-issued case. The value is the key-values defined in section 2.1 of the OpenID Connect Registration serialized into JSON object. The server may require 

Further, add the following to the example:

	“registration”: {
		“redirect_uris”: “https://rp.com/authz/callback”,
		“logo_url”: “https://rp.com/logo.png”,
		“jwk_url”=“https://rp.com/public_key.jwk”,
		“ id_token_encrypted_response_alg”: “RSA1_5 A128CBC”
	}

[Nat Sakimura]

self-issued clauses (in Standard and Implicit) states that client_id == redirect_url for self-issued provider. Thus, redirect_urls are not needed.

Other things like log_url, jwk_url, userinfo_encrypted_response_algs etc. should probably be found through the Client Discovery, which is not defined right now. IMHO, it is a good practice for an RP to publish client meta-data through some mechanism.

Thus, I suggest this ticket is to be reassigned to Discovery.

Perhaps like policy_url, add metadata_url in the request. (BTW, from it, policy_url can be obtained.) Then, the URL will return what was supposed to be sent with the registration request in JSON format.

[Nat Sakimura]

Since I am not getting any feedback on the registration_url, I am abandoning it. Client always has a way to push an object, so that may be better.

[Nat Sakimura]

Fixed #582 - Messages - 2.1.2.1 Overlay client request registration over the authentication request"

→ 58b0b29e5b3b