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.