Registration needs update capability too

Issue #865 resolved
Brian Campbell created an issue

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.

Comments (6)

  1. Brian Campbell reporter

    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.

  2. 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.

  3. 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.

  4. Log in to comment