Apparently, I did not upload the right version.<br>
<br>
I noticed at least some of the errors (in copy+paste) after initial pointing out of Torsten and meant to have fixed them and uploaded them, but I apparently did not.<br>
<br>
I am travelling now but once I get to a suitable network connection etc., I will upload the correct version.<br>
<br>
Sorry for the confusion. <div>
<br>
Nat</div><div><br></div><div>P.S. I thought I have sent this message out <span></span>before flying but apparently it did not go out perhaps due to the spotty connection. I am in LAX now waiting in a line for the security. <br>
<br>
2013/2/4 Mike Jones <<a href="javascript:;" onclick="_e(event, 'cvml', 'Michael.Jones@microsoft.com')">Michael.Jones@microsoft.com</a>>:<br>
> Thanks for doing this. It helps make apparent the current differences<br>
> between the OAuth dynamic registration spec and the Connect dynamic<br>
> registration spec.<br>
><br>
><br>
><br>
> I’ve read the differences in your doc from the current Connect spec. I saw<br>
> the following changes:<br>
><br>
> - Moved Terminology section out of Introduction<br>
<br>
yes.<br>
<br>
><br>
> - Added several terminology definitions<br>
<br>
yes.<br>
<br>
><br>
> - Deleted the “operation” parameter<br>
<br>
yes.<br>
<br>
><br>
> - Deleted most of “rotate_secret”<br>
<br>
had to remove all of them.<br>
<br>
><br>
> - Added Client Read Request (GET)<br>
<br>
Yes. For discussion to be concrete.<br>
<br>
><br>
> - Added Client Delete Request (DELETE)<br>
<br>
Yes. For discussion to be concrete.<br>
<br>
><br>
> - Added “Self URL”<br>
<br>
Yes. For discussion to be concrete.<br>
<br>
><br>
> - Added “_links”<br>
<br>
Yes. For discussion to be concrete.<br>
<br>
><br>
> - Removed “access_token” parameter from Client Registration and Update<br>
> Request<br>
><br>
> - Undid the edits that addressed<br>
> <a href="https://bitbucket.org/openid/connect/issue/698/messages-12-terminology-inconsistent-use" target="_blank">https://bitbucket.org/openid/connect/issue/698/messages-12-terminology-inconsistent-use</a><br>
<br>
I started to work off the local copy just by pulling and not updating it seems :-( Will see the diff and re-apply them.<br>
<br>
><br>
> - Added two Editor’s Notes<br>
<br>
Yes.<br>
<br>
><br>
> - Changed the Japanese client name<br>
<br>
The original was a direct translation of My Application,<br>
but that was sooo awkward because we really do not<br>
say "my" in Japanese. So, I changed it to something<br>
less awkward.<br>
<br>
><br>
> - Changed value of example registration_access_token<br>
><br>
> - Added “scope” to the example response (which isn’t defined in the spec)<br>
><br>
> - Added “grant_type” to the example response (which isn’t defined in the<br>
> spec)<br>
><br>
> - Removed these fields from the example response:<br>
> token_endpoint_auth_method, application_type, redirect_uris, client_name,<br>
> client_name_#ja-Jpan-JP, subject_type, sector_identifier_url,<br>
> userinfo_encrypted_response_alg, userinfo_encrypted_response_enc<br>
><br>
> - Added issued_at<br>
><br>
> - Added client update example (that seems to be missing many parameters<br>
> that were present in the registration request example)<br>
><br>
> - Changed the history entries for -14 and -08<br>
><br>
> - Changed where line breaks occur in many places in the XML source (making<br>
> diffing the .xml source quite difficult)<br>
><br>
><br>
><br>
> If I missed any other changes, please let me know. I haven’t diffed your<br>
> edited version with the OAuth spec. I assume many/most of the changes made<br>
> were made to match the OAuth draft.<br>
><br>
><br>
><br>
> I was originally thinking that I would just review the changes and check<br>
> them in, but there’s several changes that were made that haven’t been<br>
> discussed by the working group and several changes that I believe were<br>
> probably unintended, such as removing the fields from the example response,<br>
> adding undefined fields to the example response, reverting the issue #698<br>
> changes, editing the history entries, and reformatting much of the XML, so I<br>
> decided not to check anything in based on this draft for now. We should<br>
> probably figure out which of these changes we should actually apply to the<br>
> current draft and then check only those in. Let’s talk about this on the<br>
> Monday call.<br>
><br>
><br>
><br>
> Also, we should talk about the proposal in your editor’s note to change from<br>
> a form encoded request to a JSON request.<br>
><br>
><br>
><br>
> Thanks again for working to help us understand the ways in which the two<br>
> specs are and aren’t aligned.<br>
><br>
><br>
><br>
> Thanks again,<br>
><br>
> -- Mike<br>
><br>
><br>
><br>
> From: Nat Sakimura [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'sakimura@gmail.com')">sakimura@gmail.com</a>]<br>
> Sent: Sunday, February 03, 2013 1:55 AM<br>
> To: Mike Jones<br>
> Cc: John Bradley; Vladimir Dzhuvinov / NimbusDS;<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'openid-specs-ab@lists.openid.net')">openid-specs-ab@lists.openid.net</a> Group; Justin Richer<br>
><br>
><br>
> Subject: Re: [Openid-specs-ab] Dynamic Client Registration<br>
><br>
><br>
><br>
> Before getting this mail, I already added GET and DELETE.<br>
><br>
> GET would not change the footprint at all, since its functionality is<br>
> actually included in the POST (update).<br>
><br>
> Normative text in the DELETE is just two lines so it can be easily added or<br>
> removed.<br>
><br>
> Hard part is what John has pointed out - whether we really want to allow the<br>
> client to de-register.<br>
><br>
><br>
><br>
> Here are the changed drafts:<br>
><br>
> <a href="http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html" target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html</a><br>
><br>
> <a href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml" target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml</a><br>
><br>
><br>
><br>
> Nat<br>
><br>
><br>
><br>
> 2013/2/3 Mike Jones <<a href="javascript:;" onclick="_e(event, 'cvml', 'Michael.Jones@microsoft.com')">Michael.Jones@microsoft.com</a>><br>
><br>
> At least for Connect, I believe that we want to define only the operations<br>
> that are essential to making Connect work. So for instance, unregistering<br>
> clients and retrieving registration state aren't actually necessary<br>
> operations, and so I would not add these at the present time. We want to<br>
> keep the implementation footprint as small as possible.<br>
><br>
> -- Mike<br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="javascript:;" onclick="_e(event, 'cvml', 'openid-specs-ab-bounces@lists.openid.net')">openid-specs-ab-bounces@lists.openid.net</a><br>
> [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', '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="javascript:;" onclick="_e(event, 'cvml', 'openid-specs-ab@lists.openid.net')">openid-specs-ab@lists.openid.net</a> Group<br>
> Subject: Re: [Openid-specs-ab] Dynamic Client Registration<br>
><br>
> As you point out the client_id was removed when we went to OAuth<br>
> authentication by the client for updates.<br>
><br>
> I can see in a developer environment you may want to allow the master token<br>
> to modify any of the clients created by it thus requiring a separate<br>
> 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<br>
> management.<br>
><br>
> I would not want to de register a app. I could perhaps be convinced to have<br>
> 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<br>
> 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<br>
> a client management extension.<br>
><br>
> I am also receptive to the use of GET to inspect the current client config<br>
> 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"<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', '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="javascript:;" onclick="_e(event, 'cvml', '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="javascript:;" onclick="_e(event, 'cvml', '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="javascript:;" onclick="_e(event, 'cvml', '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>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
><br>
> Chairman, OpenID Foundation<br>
> <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
<br>
<br>
<br>
--<br>
Nat Sakimura (=nat)<br>
Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<br>
</div><br><br>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>