Stateless Registration Discovery/Messages

[John Bradley]

OpenID Connect currently requires registration for clients.

Clients using a self issued IdP may register as part of the authorization request, by sending the "registration" parameter containing a JSON object, and using there redirect_uri as the client_id.

There is a desire by some IdP to allow clients that are not pre-registerd to access a minimal set of claims for a user. This could be done with the existing method by using the existing "registration" parameter to signal that the has not pre registered.

Almost everything needed for this is in the current spec. The needed additions would be an indication in Discovery that the Authorization server supports this, and something in messages saying that if the client is not pre-registerd it MUST send the "registration" parameter with at-least {} as the contents if no other parameters are needed.

The AS would formulate a normal response verifying the client_id and the redirect_uri match as is specified for the self_issued AS, then issue a normal code or implicit response.

This would allow a IdP to return the "sub" claim to a client for SSO only without any real security concerns as the Audience prevents replaying across clients, and nonce if used (I think should be recommended) prevents replay across browsers.

[John Bradley]

The other alternative is to do a form of stateless registration.

The Dynamic registration endpoint could issue an encrypted assertion as the client_id, containing the redirect_uri and a client secret plus any other information required by the authorization endpoint.

We could issue an assertion for the client to use as it's authentication to the token endpoint in the code flow however that only goes to the token endpoint, we would still need the client info at the authorization endpoint for redirect_uri and other parameters.

One thing to remember is that anything passed over the front channel is no longer a secret, that is why we would want to issue a secret from the dynamic registration endpoint that the client uses to authenticate but have it encrypted.

Using an encrypted assertion as client_id is currently possible as an implementation optimization with the current spec. The only thing we may need to look at is that some of the discovery/registration options may not be available to clients encoding the information into the client_id. We may want to add something to discovery to say if you are registering without a registration token you are limited to some subset of attributes or configuration.

For the implicit flow the client_id could just be the signed redirect_uri and other parameters encryption would not be needed.

[Nat Sakimura]

Again, I am weary of adding "features" to the core specifications at this point. From what I see, we could deal with this as an extension, and as long as that is true, we should deal with it that way.

At this point in time, we should not make a normative change unless it is a security hole or something.

[Michael Jones]

We will add an implementer's note saying that stateless registration is possible, that the method is OP-specific, that it could be done by encoding state in the Client ID, and also referencing Justin & John's draft as one possible way of doing it. We will also say that no Registration Access Token is returned in this case.

[Michael Jones]

Fixed #863 - Described how to perform stateless dynamic client registration.

→ <<cset 6bfa9136b7b1>>