[Openid-specs-ab] Dynamic Client Registration

Justin Richer jricher at mitre.org
Wed Feb 6 22:10:06 UTC 2013


I agree that the normative language is odd there. I'm having a tough 
time differentiating what's required for the server to support vs. 
what's required for the client to send. Thus the editor's note in there, 
and any help in this regard would be greatly appreciated!

  -- Justin

On 02/06/2013 05:06 PM, Nat Sakimura wrote:
> 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 <mailto: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
>>     <mailto: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 operationparameter.
>>       * Fixed #745 - Deleted the rotate_secretoperation.
>>       * Changed the Japanese client name to make it sound more natural.
>>       * Added optional issued_atresponse 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]
>>     *Sent:* Monday, February 04, 2013 2:03 PM
>>     *To:* Mike Jones
>>     *Cc:* openid-specs-ab at lists.openid.net
>>     <mailto: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/b9335096/attachment-0001.html>


More information about the Openid-specs-ab mailing list