Registration needs update capability too

[Brian Campbell]

Connect Dynamic Client Registration (draft 19) currently only allows a client to register and read it's own registration info.

There was, at one time, an intentional decision that those two operations were sufficient. The thinking was that, if a client wanted to update some data (even a credential), it would just do a new registration. But there are a few problems with this:

1) All user approvals at the AS/OP for that client will be lost with this approach as the client will be assigned a new client id (Don Bradley pointed out this now rather obvious issue to me in Berlin last week).

2) The AS/OP looses its ability to log/audit/monitor interactions with the client across the update.

3) It will result in orphaned client records at the AS/OP, which could be a problem from a maintenance and even security perspective.

All that and the current level of uncertanty in the IETF OAuth WG around registration suggests that a more robust set of operations (full CRUD) is needed in Connect registration.

[Michael Jones]

Update is not possible for stateless servers (because it would change the client_id).

[Brian Campbell]

That's true if all the info is encoded in the client_id and the client id is immutable. Both assumptions may need to be challenged as the idea of stateless servers is considered.

[Michael Jones]

Per the 19-Sep-13 call, in the stateless registration case, OpenID registration shouldn't require returning a registration access token. Justin's refactored OAuth draft actually already allows this.

[Michael Jones]

We will say that work on registration update is still ongoing in the IETF and that some implementations may choose to implement update either via the current IETF spec or a future spec.

[Michael Jones]

Fixed #865 - Described the possibility of implementations using the update operation defined by the OAuth Dynamic Registration spec

→ <<cset 7623ea664ba2>>