[Openid-specs-ab] Dynamic Client Registration

Nat Sakimura sakimura at gmail.com
Sat Feb 2 17:12:44 UTC 2013

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>

> 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.
> Nat
> 2013/2/2 Vladimir Dzhuvinov / NimbusDS <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
>> 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
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

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

More information about the Openid-specs-ab mailing list