Registration 3 - Is the Client Update operation really needed?

[Michael Jones]

The working group has spent the better part of the last two days debating fine points of what Update should and shouldn't mean in specific corner cases and pointing out additional corner cases to one another. Client Update is clearly one of the most underspecified features of Connect, at this point.

Is Update essential? Or would be be doing everyone a service by deleting it for the implementers drafts and letting people know that they need to just do a new registration to obtain different client parameters?

[Michael Jones]

We agreed to drop this for now for Connect

[Former user]

Just so it's on the record here, this is my understanding from the call of what this means:

• Connect will drop the "client update" semantics
• OAuth2 DynReg will keep the "client update" semantics and the OAuth WG will hash out all the hard corner cases needed to make it work there
• Connect will, if it's ready and useful, adopt the client update semantics defined in DynReg
• Connect will keep the Registration Access Token functionality to support potential other uses like client configuration read and facilitate reintegration of update (and possibly other) functionality

[Vladimir Dzhuvinov]

This looks like a good compromise for now guys. So thanks for suggesting it. I believe we'll be able to make a more informed decision on update when we have more early impl experience on registration in practice.

[Michael Jones]

Fixed #755 - Removed client update operation. Fixed #751 - Added client read operation. Fixed #749 - Added "registration_access_url". Fixed #756 - State that an updated "client_secret" value can be returned by a read operation.

→ <<cset 62fea9ed07e0>>