[Openid-specs-ab] Dynamic Client Registration

Nat Sakimura sakimura at gmail.com
Sat Feb 2 12:56:37 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130202/051adea8/attachment.html>


More information about the Openid-specs-ab mailing list