<div dir="ltr">Just scanned the diff. It seems fine. You just inserted extension points to the Core. That's fine although ideally it should be dealt with OAuth itself. (Is there an early revision or defect reporting mechanism at IETF?)<div>
<br></div><div>I thought you were going to either change the existing flows or insert the whole new flow into the Core, and I was very much against that. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/10/19 Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Full HTML versions<u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html" target="_blank">
http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html</a><u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html" target="_blank">
http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html</a><u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13.html" target="_blank">
http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13.html</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Word versions showing diffs from Bitbucket versions:<u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx" target="_blank">
http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx</a><u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx" target="_blank">
http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx</a><u></u><u></u></p>
<p class="MsoNormal"> <a href="http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13-diffs.docx" target="_blank">
http://self-issued.info/docs/openid-connect-core-1_0-18-Oct-13-diffs.docx</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Status updates: Multiple Response Types now uses the Response Mode identifier “<span style="font-family:"Courier New"">form_post</span>” (rather than “<span style="font-family:"Courier New"">POST</span>”) and specifies the use of the application/x-www-form-urlencoded
encoding for the form posted responses. Discovery includes the “<span style="font-family:"Courier New"">response_modes_supported</span>” parameter. In Core, rather than saying things like “MUST be fragment encoded” we now say things like “MUST be fragment
encoded, unless a different Response Mode was specified”.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As for where we go from here, from George’s proposal and Nat’s +1 to it, I believe that the only part of these proposed changes that there’s still active debate about is whether the “<span style="font-family:"Courier New"">form_post</span>”
Response Mode should be defined as an extension to Multiple Response Types or in Multiple Response Types itself. Even those who are skeptical of trying to include the new binding as a final part of the specs appear to agree that we’re right to generalize
the language in Core, etc. to *<b>permit</b>* such bindings to be specified and used in the future – which is what’s really been done in Core and Discovery and in all of the Multiple Response Types changes other than the subsections that actually define the
new Response Mode.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m saying that, because given that as editor, I now already have numerous feedback comments to incorporate (thanks Vladimir and Torsten!), and I plan to start incorporating them tomorrow. Unless I hear serious objections to proceeding
in this manner, I plan to check in the sources to the above and make the changes against those versions. I recognize that if “<span style="font-family:"Courier New"">form_post</span>” becomes a separate extension, that means I’d need to separate it from Multiple
Response Types. That’s not hard. However, I believe that all the other changes, which *<b>enable but do not define</b>* alternative Response Modes, would stay. It will be much easier for me as editor to work that way, rather than maintaining two sets of
change branches and merging them later. (This matters because our time is short – especially the time before Monday’s meeting.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks for the vigorous discussion the past few days and for all of your demonstrated passion both for finishing and for a high quality outcome. Keep those spec reviews coming!<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> Cheers,<u></u><u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
</div>
</div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <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>
</div>