<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks for doing this. It helps make apparent the current differences between the OAuth dynamic registration spec and the Connect dynamic registration spec.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’ve read the differences in your doc from the current Connect spec. I saw the following changes:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Moved Terminology section out of Introduction<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added several terminology definitions<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Deleted the “operation” parameter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Deleted most of “rotate_secret”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added Client Read Request (GET)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added Client Delete Request (DELETE)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added “Self URL”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added “_links”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Removed “access_token” parameter from Client Registration and Update Request<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Undid the edits that addressed
<a href="https://bitbucket.org/openid/connect/issue/698/messages-12-terminology-inconsistent-use">
https://bitbucket.org/openid/connect/issue/698/messages-12-terminology-inconsistent-use</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added two Editor’s Notes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Changed the Japanese client name<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Changed value of example registration_access_token<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added “scope” to the example response (which isn’t defined in the spec)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added “grant_type” to the example response (which isn’t defined in the spec)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Removed these fields from the example response: token_endpoint_auth_method, application_type, redirect_uris, client_name, client_name_#ja-Jpan-JP, subject_type,
sector_identifier_url, userinfo_encrypted_response_alg, userinfo_encrypted_response_enc<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added issued_at<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Added client update example (that seems to be missing many parameters that were present in the registration request example)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Changed the history entries for -14 and -08<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - Changed where line breaks occur in many places in the XML source (making diffing the .xml source quite difficult)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If I missed any other changes, please let me know. I haven’t diffed your edited version with the OAuth spec. I assume many/most of the changes made were made
to match the OAuth draft.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I was originally thinking that I would just review the changes and check them in, but there’s several changes that were made that haven’t been discussed by
the working group and several changes that I believe were probably unintended, such as removing the fields from the example response, adding undefined fields to the example response, reverting the issue #698 changes, editing the history entries, and reformatting
much of the XML, so I decided not to check anything in based on this draft for now. We should probably figure out which of these changes we should actually apply to the current draft and then check only those in. Let’s talk about this on the Monday call.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also, we should talk about the proposal in your editor’s note to change from a form encoded request to a JSON request.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks again for working to help us understand the ways in which the two specs are and aren’t aligned.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Thanks again,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Nat Sakimura [mailto:sakimura@gmail.com]
<br>
<b>Sent:</b> Sunday, February 03, 2013 1:55 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> John Bradley; Vladimir Dzhuvinov / NimbusDS; openid-specs-ab@lists.openid.net Group; Justin Richer<br>
<b>Subject:</b> Re: [Openid-specs-ab] Dynamic Client Registration<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Before getting this mail, I already added GET and DELETE. <o:p></o:p></p>
<div>
<p class="MsoNormal">GET would not change the footprint at all, since its functionality is actually included in the POST (update). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Normative text in the DELETE is just two lines so it can be easily added or removed. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hard part is what John has pointed out - whether we really want to allow the client to de-register. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Here are the changed drafts: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html">http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml">http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2013/2/3 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><o:p></o:p></p>
<p class="MsoNormal">At least for Connect, I believe that we want to define only the operations that are essential to making Connect work. So for instance, unregistering clients and retrieving registration state aren't actually necessary operations, and so
I would not add these at the present time. We want to keep the implementation footprint as small as possible.<br>
<span style="color:#888888"><br>
<span class="hoenzb"> -- Mike</span></span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
-----Original Message-----<br>
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of John Bradley<br>
Sent: Saturday, February 02, 2013 9:20 AM<br>
To: Vladimir Dzhuvinov / NimbusDS<br>
Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a> Group<br>
Subject: Re: [Openid-specs-ab] Dynamic Client Registration<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">As you point out the client_id was removed when we went to OAuth authentication by the client for updates.<br>
<br>
I can see in a developer environment you may want to allow the master token to modify any of the clients created by it thus requiring a separate client_id parameter.<br>
That is a reasonable reason to have that parameter.<br>
<br>
As far as de registering a client we start down a slippery slope of full API management.<br>
<br>
I would not want to de register a app. I could perhaps be convinced to have a app state where you could have "enabled": false.<br>
<br>
That way an admin could disable a compromised client_id.<br>
<br>
However that raises questions like should an app be able to re enable itself? Should that only be modifiable through the developer credential?<br>
<br>
Disabling is a bit of a can of worms so I am cautious, perhaps it belongs in a client management extension.<br>
<br>
I am also receptive to the use of GET to inspect the current client config state without updating it.<br>
<br>
John B.<br>
<br>
<br>
<br>
<br>
<br>
On 2013-02-02, at 7:12 AM, "Vladimir Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>> wrote:<br>
<br>
> Thank you John for explaining the story behind the current spec.<br>
><br>
><br>
>> I would like to remove rotate_secret as it is not restful for those<br>
>> that care and not especially useful.<br>
><br>
> 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,<br>
> to 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<br>
> all update operations.<br>
><br>
><br>
> Vladimir<br>
> _______________________________________________<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>
<br>
_______________________________________________<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>
_______________________________________________<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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>