Hi Vladimir,<div> <div>I think there should be client_id in the request as well. <div><br></div><div>See <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg10636.html">http://www.ietf.org/mail-archive/web/oauth/current/msg10636.html</a> on what I think. </div>
<div><br></div><div>In fact, I like it to go even further, but that may be too big a departure. </div><div>The cleanest way is to do like <a href="http://www.ietf.org/mail-archive/web/oauth/current/msg10643.html">http://www.ietf.org/mail-archive/web/oauth/current/msg10643.html</a> </div>
<div>but to avoid the path pollution, we would have to introduce URI template (RFC6570) </div><div>and that means the client always need to be able to parse URI template </div><div>and that is probably asking too much to the client.  </div>
<div><br></div><div>Nat</div><div><br><div class="gmail_quote">2013/2/2 Vladimir Dzhuvinov / NimbusDS <span dir="ltr"><<a href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you John for explaining the story behind the current spec.<br>
<div class="im"><br>
<br>
> I would like to remove rotate_secret as it is not restful for<br>
> those that care and not especially useful.<br>
<br>
</div>If we think in terms of REST and CRUD, is there a scenario where a<br>
client may want to unregister? E.g. for an  IdP service that is paid<br>
for?<br>
<br>
I also have a real case with a customer who wishes to add an optional<br>
manual registration UI which should speak to the dynamic registration<br>
endpoint for all requests:<br>
<br>
(1) client admin registering app,<br>
<br>
(2) client admin viewing existing registered app details,<br>
<br>
(3) client admin updating registered app details,<br>
<br>
(4) client admin deleting app registration.<br>
<br>
<br>
The current endpoint spec that we have covers (1) and (3); (2) is<br>
however only indirectly covered, using the update operation as a work<br>
around, and (4) not at all.<br>
<br>
The missing "client_id" from update operations also makes it hard for<br>
trusted third parties, such as the server hosting the manual reg UI, to<br>
handle updates, because the access_token is directly tied to the<br>
client_id and is used to derive it. If the client_id was specified<br>
explicitly we could then issue an access_token the reg UI server for all<br>
update operations.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Vladimir<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>

</div></div></div>