[Openid-specs-ab] Dynamic Client Registration

[Nat Sakimura]

2013/2/5 Mike Jones <Michael.Jones at microsoft.com>

>  This looks substantially better than the last version.  Thanks for doing
> it!
>

It was my blunder. I kept uploading the old version for a very silly
reason.


> ****
>
> ** **
>
> The one thing that immediately surprised me is that the client_update
> request doesn’t have a client_id parameter.  I realize that you’re
> expecting it to be inferred from the access token, but it would be a good
> cross-check to always include it – in part to make sure that the caller
> actually has the right client_id, and in part, so the “register” and
> “update” functions can easily be syntactically distinguished.
>

There are several reasons for it.

1.  d16 did not include client_id in the update request <-- biggest reason.
2. client_id can be inferred from the Self URL.
    In fact, it should include the client_id in some form that the server
likes.
3. client_id can be inferred from the Access Token as well.


> ****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com]
> *Sent:* Monday, February 04, 2013 2:03 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net Group; Justin Richer
>
> *Subject:* Re: [Openid-specs-ab] Dynamic Client Registration****
>
> ** **
>
> OK. Now I have uploaded the correct Discussion Draft 17.
>
> HTML:
> http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html
> diff:
> http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-diff-16-17.txt
> ****
>
>  XML:
> http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml
> ****
>
> TXT (d16):
> http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d16.txt
> ****
>
> TXT (d17):
> http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d17.txt
> ****
>
>
> [Changes] ****
>
> -17 discussion version****
>
> **·         **Moved Terminology section out of Introduction to form an
> independent section and added several terminology definitions****
>
> **·         **Deleted the operation parameter****
>
> **·         **Deleted the rotate_secret****
>
> **·         **Added Client Read Request (GET)****
>
> **·         **Added Client Delete Request (DELETE)****
>
> **·         **Added "Self URL"****
>
> **·         **Added _links****
>
> **·         **Added Editor's Notes****
>
> **·         **Changed the Japanese client name to make it sound more
> natural****
>
> **·         **Added issued_at****
>
> **·         **Added client update example (that seems to be missing many
> parameters that were present in the registration request example)****
>
> **·         **Cleand up the indents****
>
> [Remarks] ****
>
>    - The operation parameter was removed but since the URL for the
>    registration and other operations are different, there should be no problem
>    in finding out what action should be taken. ****
>    - The URL for update etc. (Self URL) are given in _links/self/href.
>    For servers' backward compatibility with the current implementations, it
>    could be set like
>    https://server.example.com/connect/register?operation=client_update so
>    that the existing code is likely not break (if the web application
>    framework is putting GET and POST parameters together into an object) or
>    needs only minor change. Clients needs to read this value and store, so it
>    is a bigger change. ****
>
>  Unfortunately, I will be able to join the call only very briefly due to
> my flight schedule. ****
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>



-- 
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/20130205/770a5b9b/attachment.html>