Registration - Add Scalability Consideration (and concern)

[Nat Sakimura]

While Dynamic Registration enables open registration, it begs for some scalability considerations.

If the server side is a massively distributed infrastructure on the global base, you just cannot expect that the registration record to propagate fast enough to enable the authorization request immediately after that.

Consider this:

The client was in Chile and the browser was in Japan, and the server was globally distributed. Suppose the client was not registered with the server. The user in Japan accessed the web client in Chile. The client in Chile likely to register to the server in Chile, and redirects the user's browser to the authorization endpoint. The browser is likely to access the server in Japan, within a few hundred milliseconds. It is entirely possible that the state propagation from Chile to Japan has not finished and the server will return the error response.

We should at least note this. This may be one of the reason why people like Google do not want to support the dynamic registration.

The only way out is actually to make the server stateless. i.e., Send the registration request with the authorization request.

BTW, the self issued spec at http://openid.bitbucket.org/openid-connect-standard-1_0.html#self_issued seems to be different than ours and Axel's implementation. It probably would not work. We probably need to fix it one way or another before going to the implementer's draft.

[Vladimir Dzhuvinov]

Combining the registration and authz requests? Wow :)

[Nat Sakimura]

Maybe not (but this is how clients talk to Self Issued OP, btw.)

I and John discussed this F2F and the following is the conclusion:

Provide the following with the registration response:

• Provisioning Status flag (pending, active, suspended);
• Polling interval check back time in number of seconds;
• A human readable explanation;

[Michael Jones]

We decided not to add anything to the normative text about possible registration delays.

We will defer decision about whether to add a status field (pending, active, suspended) until the discussions about what DELETE means.