Registration - Clarify Update; add normative text

[Nat Sakimura]

It was not very clear in d14 whether Update was a replacement or update. It only had a non-normative (i.e., no MUST, SHOULD, etc.) text saying "Client Update Requests replace all previous parameters set for a client_id." Were it to be a normative text, it had to state something like:

Upon the receipt of the request, the server MUST update all the registered parameters set for a client_id in the request with the received value, MUST update all the registered parameters not included in the request but with a server default with the current server default value, and MUST delete any other previously registered parameters.

This means

(1) the client has to store all the returned value from the registration request [it is OK but we probably should state it if so.];
(2) the update request MUST include all the values in (1), otherwise it may change the values; (3) the update request creates new parameters if the server defaults were added between the registration and update;

Whether this is the intended behavior not, we have to clarify in a normative text. Otherwise, we will lose the interoperability.

[Michael Jones]

This has already been clarified in -15. http://openid.bitbucket.org/openid-connect-registration-1_0.html#ClientUpdateRequest says: “All Client Metadata values, other than the Client ID and Registration Access Token are replaced by this operation.” I think that this is already pretty clear, but we could add the “MUST delete” language if you think it would make it clearer.

(1) The client can simply remember what values it used in the initial registration and apply diffs to those for the changes that it wants. The client actually doesn’t need the returned values at all. (And see the thread “Fields that the server has provisioned on the client's behalf” for a discussion of the ambiguities that trying to use the returned values could cause.)

(2) Actually, the client likely only needs to include all the values in the initial registration request – not any of those returned – other than the client_id and using the registration_access_token.

(3) Yes, that could occur. This actually argues against trying to pass returned values (other than the client_id and registration_access_token) back in the update request.

All this makes me think that to clear up this ambiguity, we probably want to say that the returned values, other than client_id and registration_access_token, are informational and should not be passed back to the registration endpoint in update requests.

[Michael Jones]

Placed on hold since this issue is about the Registration Client Update operation and we have removed that operation, per issue #755.

[Michael Jones]

We removed the Update operation, so we will resolve this as "wontfix".

[Nat Sakimura]

Actually, it does not mean that this was not needed. It was solved as a side effect of removing the 'update' so it is rather fixed by the fact of that.