> When sending an update, a client MUST send all metadata fields returned > from the server in its initial registration or previous read or update > call, including its client_id. A server MAY replace any missing or > invalid fields with default values, or it MAY return an error as > described in the Error Response section. A server MUST return all > provisioned fields in its response. A server MUST NOT change the > client_id field. A server MAY change the client_secret and/or > refresh_access_token fields.
Say the client registered some value. Sometime later, the server changed a value due to some policy or security reasons etc. The client when UPDATES with the previously registered value, what is going to happen to the changed value? >> DELETE to be used correctly is I think going to delete the client_id and all >> associated tokens and cause a ripple effect in removing grants associated >> with that client_id. > > This is how I would interpret it as well. It's de-provisioning the > client, not resetting it. For DELETE, I can think of an attack such that 1. Register as a client. 2. Send spam links to random users. 3. When user "authorizes", suck the user data such as contacts out. 4. DELETE the registration and disappear. To prevent something like this, it should probably be something more akin to "suspend" rather than completely de-provisioning. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
