[Openid-specs-ab] Dynamic Client Registration

Wed Feb 6 22:06:45 UTC 2013

Thanks Justin!

Looks pretty good.
I still feel that REQUIRED, etc. in the clause 2. a bit awkward, though. I
feel that they should be in the respective request clauses.

Nat

2013/2/6 Justin Richer <jricher at mitre.org>

>  I've incorporated many of Nat's design choices into the OAuth DynReg
> document and have posted to the OAuth list for feedback. This includes use
> of RESTful HTTP verbs and the link structure for communicating the endpoint
> URLs. I also incorporated some of his editor's notes which also came up
> earlier on the OAuth list, including JSON-in.
>
> I left in a method to do rotate_secret, pending discussion on the
> functionality. It parallels the client_update function in many ways.
>
> I would encourage everyone to read over the new DynReg spec before the
> OIDC call tomorrow.
>
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg
>
>  -- Justin
>
>
> On 02/06/2013 02:17 AM, Mike Jones wrote:
>
>  Updated versions attached that also address Brian Campbell’s review
> comments on Registration.  The versions at http://openid.bitbucket.org/were also updated.
> ****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Mike Jones
> *Sent:* Tuesday, February 05, 2013 7:12 PM
> *To:* 'Nat Sakimura'
> *Cc:* openid-specs-ab at lists.openid.net Group; Justin Richer
> *Subject:* RE: [Openid-specs-ab] Dynamic Client Registration****
>
> ** **
>
> I’ve applied the parts of Nat’s discussion draft that implement working
> group decisions to the current registration draft.  Changes applied are:**
> **
>
> ** **
>
> ·        Tracked wording changes intended to better harmonize with the
> OAuth registration draft****
>
> ·        Corrected version number to -15.  (Apparently it had been
> erroneously incremented twice – once by me, once by Nat)****
>
>    - Fixed #746 - Deleted the operation parameter. ****
>    - Fixed #745 - Deleted the rotate_secret operation. ****
>    - Changed the Japanese client name to make it sound more natural. ****
>    - Added optional issued_at response value. ****
>    - Added client update example.****
>
> I did not apply these changes:****
>
> ·        Moved Terminology section out of Introduction to form an
> independent section and added several terminology definitions – This
> would make the section hierarchy of registration different than all the
> other Connect specs****
>
> ·        Added Client Read Request (GET) – No working group decision to
> add this operation****
>
> ·        Added Client Delete Request (DELETE) – No working group decision
> to add this operation****
>
> ·        Added "Self URL" – No working group decision to add this
> functionality****
>
> ·        Added _links – No working group decision to add this
> functionality****
>
> ·        Added Editor's Notes – We should be tracking issues in the issue
> tracker instead****
>
> ·        Cleaned up the indents – Were there were no text changes from
> the original version, I tried to keep the exact text from the original to
> facilitate diff’ing the .xml source.  Where there were changes, I tried to
> keep Nat’s .xml formatting.****
>
> ·        I also did not apply a big unlisted change, which had changed
> the semantics of Client Update from replace-all-fields to
> update-only-listed-fields – No working group decision to change this
> functionality****
>
> Justin, it would be good if you applied the changes made in this version
> to the OAuth registration draft as well, because there were numerous bug
> fixes – especially in the examples.  (BTW, you can’t put more than 70
> characters in an <artwork> line or xml2rfc complains when producing the
> .txt version.)****
>
> ** **
>
> The .xml, .unpg (unpaginated text), and .html versions are attached.****
>
> ** **
>
> I’ll send a few questions about the current text separately.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura at gmail.com <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/20130206/548daeae/attachment.html>