We did discuss this issue in the connect WG. The decision was made to always completely replace. That prevents unknown states if a update fails.
I think the always replace everything rule is simpler, though admittedly more bandwidth is required. However bandwidth is not a significant factor for this as far as I know. John B. On 2013-01-04, at 8:55 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > The client_update operation in > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something > different than the operation upon which it was based > fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html. > Specifically, while the OpenID Connect operation replaces all field values, > the OAuth operation allows only selective fields to be replaced, designating > fields to remain unchanged by specifying their value as the empty string (“”). > > I'm personally not happy with the change to the semantics of client field > inclusion. Updating some but not all fields is a substantially more > complicated operation than replacing all fields. Is there some use case that > motivates this? I don't think it's a substantial burden on the registering > party to remember all the field values from the initial registration and then > selectively use them for update operations, when needed. Then the work goes > to the (I suspect rare) parties that need partial update - not to every > server. It complicates the simple case, rather than pushing the complexity > to the rare case, violating the design principle “make simple things simple > and make more complicated things possible”. > > Is anyone opposed to updating the OAuth Registration semantics to match the > Connect registration semantics? Is so, why? > > Thanks, > -- Mike > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth