[Openid-specs-ab] Dynamic Client Registration

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Sat Feb 2 10:12:07 UTC 2013

Thank you John for explaining the story behind the current spec.

> I would like to remove rotate_secret as it is not restful for 
> those that care and not especially useful.

If we think in terms of REST and CRUD, is there a scenario where a
client may want to unregister? E.g. for an  IdP service that is paid

I also have a real case with a customer who wishes to add an optional
manual registration UI which should speak to the dynamic registration
endpoint for all requests: 

(1) client admin registering app, 

(2) client admin viewing existing registered app details, 

(3) client admin updating registered app details, 

(4) client admin deleting app registration.

The current endpoint spec that we have covers (1) and (3); (2) is
however only indirectly covered, using the update operation as a work
around, and (4) not at all.

The missing "client_id" from update operations also makes it hard for
trusted third parties, such as the server hosting the manual reg UI, to
handle updates, because the access_token is directly tied to the
client_id and is used to derive it. If the client_id was specified
explicitly we could then issue an access_token the reg UI server for all
update operations.


More information about the Openid-specs-ab mailing list