[Openid-specs-ab] Dynamic Client Registration

John Bradley ve7jtb at ve7jtb.com
Sat Feb 2 17:19:43 UTC 2013


As you point out the client_id was removed when we went to OAuth authentication by the client for updates.

I can see in a developer environment you may want to allow the master token to modify any of the clients created by it thus requiring a separate client_id parameter.  
That is a reasonable reason to have that parameter. 

As far as de registering a client we start down a slippery slope of full API management.  

I would not want to de register a app.  I could perhaps be convinced to have a app state where you could have "enabled": false.

That way an admin could disable a compromised client_id.

However that raises questions like should an app be able to re enable itself?   Should that only be modifiable through the developer credential?

Disabling is a bit of a can of worms so I am cautious, perhaps it belongs in a client management extension.

I am also receptive to the use of GET to inspect the current client config state without updating it.

John B.





On 2013-02-02, at 7:12 AM, "Vladimir Dzhuvinov / NimbusDS" <vladimir at nimbusds.com> wrote:

> 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
> for?
> 
> 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.
> 
> 
> Vladimir
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list