[Openid-specs-ab] Dynamic Client Registration
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.
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
> 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.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab