[Openid-specs-ab] Dynamic Client Registration

Nat Sakimura sakimura at gmail.com
Wed Feb 6 08:56:00 UTC 2013


Thanks Mike,

Comments in-line:

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

>  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:
>

So these are the discussion item.


> ****
>
> **·        **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
>

OK.


> ****
>
> **·        **Added Client Read Request (GET) – No working group decision
> to add this operation
>

If the intended behavior of the "update" was in fact "replace", then having
this is very useful.


> ****
>
> **·        **Added Client Delete Request (DELETE) – No working group
> decision to add this operation
>

We should discuss whether we need some sort of deactivation.


> ****
>
> **·        **Added "Self URL" – No working group decision to add this
> functionality****
>
> **·        **Added _links – No working group decision to add this
> functionality
>

>From my read, the working group intent was to have a clearly separated
endpoint for the initial registration and subsequent operations.
While my proposal was achieving that in a backward compatible way[1], the
current d15 does not have that. Instead, it is looking at the existence of
client_id to switch the behavior.

While this SOA like architecture is OK (and in general, that's how OAuth
is), having the ability for the server to indicate the link relations url
is one step closer to HATEOAS <http://en.wikipedia.org/wiki/HATEOAS>(aka
REST). In my proposal, _links.self.href represents the link-relationship
defined in RFC5988 <http://tools.ietf.org/html/rfc5988>and IANA Link
Relations registry<http://www.iana.org/assignments/link-relations/link-relations.xml>.
In addition, we probably should define a media-type for the response, such
as application/json+oauth, and define how the JSON should be serialized
into URL form encoding (or JSON POST etc.) in the subsequent request. That
will create a uniform interface.

To achieve this, syntactically, we would have three ways: HAL that I used
and JSON Schema. If it were JSON Schema, it would have benn
links.rel['self'][0].href instead. I found HAL-wya of being
_links.self.href  a bit easier on my eyes so I used HAL.

The third way is to use HTTP response header in the form of:

Link: <https://server.example.com/clients/1234>; rel="self";
 title="oauth client registration url"

Arguably, this is the best way for OAuth, which is currently completely
HTTP based.
Downside is that if we start having other binding (e.g., IMAP, XMPP, etc.),
then we have to fall back to HAL or other ways.

[1] by providing _links.self.href as the registration URL +
"?operation=client_update"


> ****
>
> **·        **Added Editor's Notes – We should be tracking issues in the
> issue tracker instead
>

Did you create tracker entries?


> ****
>
> **·        **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.
>

IMHO, at some point before publishing, we should clean the indent. Perhaps
creating a text without any text change but only the indent  would be good.

****
>
> **·        **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
>

Actually, it was not very clear in d14 whether it was a replacement or
update. It only had a non-normative (i.e., no MUST, SHOULD, etc.)  text
saying "Client Update Requests replace all previous parameters set for a
client_id." Were it to be a normative text, it had to state something like:

Upon the receipt of the request, the server MUST update all the registered
parameters set for a client_id in the request with the received value, MUST
update all the registered parameters not included in the request but with a
server default with the current server default value, and MUST delete any
other previously registered parameters.

This means

(1) the client has to store all the returned value from the registration
request [it is OK but we probably should state it if so.];
(2) the update request MUST include all the values in (1), otherwise it may
change the values;
(3) the update request creates new parameters if the server defaults were
added between the registration and update;

Now, the question is, is this the intended behavior?

Also, another question is that if the server changed the server default,
would this affect the currently registered values? My read is "no", but
just to make sure -- and we should clarify it in any case.


> ****
>
> 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/910089ed/attachment-0001.html>


More information about the Openid-specs-ab mailing list