[Openid-specs-ab] Dynamic Client Registration

Mike Jones Michael.Jones at microsoft.com
Sat Feb 2 20:02:00 UTC 2013

Sounds good.  Are you also making the changes to both that appear to be agreed to - removing the operation parameter and rotate_secret and putting the client_id parameter back for the update operation?

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Saturday, February 02, 2013 9:13 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: openid-specs-ab at lists.openid.net Group
Subject: Re: [Openid-specs-ab] Dynamic Client Registration

P.S. I am editing registration and oauth-dyn-reg so that they will be in the same format and can be easily compared.
I can probably share them tomorrow.

2013/2/2 Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>>
Hi Vladimir,

I think there should be client_id in the request as well.

See http://www.ietf.org/mail-archive/web/oauth/current/msg10636.html on what I think.

In fact, I like it to go even further, but that may be too big a departure.
The cleanest way is to do like http://www.ietf.org/mail-archive/web/oauth/current/msg10643.html
but to avoid the path pollution, we would have to introduce URI template (RFC6570)
and that means the client always need to be able to parse URI template
and that is probably asking too much to the client.


2013/2/2 Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com<mailto:vladimir at nimbusds.com>>
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<mailto:Openid-specs-ab at lists.openid.net>

Nat Sakimura (=nat)
Chairman, OpenID Foundation

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130202/17397384/attachment-0001.html>

More information about the Openid-specs-ab mailing list