<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 17, 2013 at 11:37 AM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks, Brian. This is really useful. I suspect I’ll be using some of your text in my write-up.
</span><span style="font-size:11pt;font-family:Wingdings;color:rgb(31,73,125)">J</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I just spent some time on the phone with Breno discussing this and he agreed that defining a POST response at this point is reasonable. When talking about
possible ways of specifying the POST response behavior, he stated the principle that when a behavioral change is being requested, that this should be done so dynamically, rather than via registration. That way, particular clients can be updated to use this
behavior without requiring a new client registration. (He likes using registration to specify behavioral restrictions, however, such as requiring particular signing/encryption algorithms, etc.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">He said that the way that he’d do it is to include a “transport=POST” parameter in the authorization request. So that’s what I’ll write up. We could later
than define “transport=postMessage”, “transport=CORS”, etc. if we decide to do so.</span></p></div></div></blockquote><div><br></div><div>I think this is sufficiently small that we might be able to undertake in a short time-frame. I believe that POST support will prove useful. I'd recommend this to be added to the new response types part of the spec: <a href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html">http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html</a>, for a number of reasons: It already has the burden to deal with the security properties of different encoding formats for different response types, and would be a small change in scope to change it to talk about 'transport' modes instead of encoding. That spec also has been stable and changed little for a long time, so the chance that it can be re-written w/o side-effects is probably higher.</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">As an aside, Breno also said that the reason that he thinks Session Management isn’t yet ready to be final, is that he’d like us to explore the option of using
a CORS transport, rather than postMessage within Session Management. I’ll leave it to Breno to say more about this.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> Thanks all,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Brian Campbell<br>
<b>Sent:</b> Thursday, October 17, 2013 8:56 AM<br>
<b>To:</b> <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Subject:</b> [Openid-specs-ab] proposed POST response type for OAuth/Connect<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">As discussed during today's call [1], attached is the pseudo-standard document I wrote up earlier this year describing an HTTP POST response type (effectively a POST binding) for OAuth/OIDC.
<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12pt">I know everyone has a lot of docs to read right now but this one is *very* short and has a good example.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">We've found this approach to work well in practice and be easy to implement.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">It can be done as a straight extension, as illustrated with this doc, or could incorporated into core connect.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">As John mentioned, the main drawback of this approach is proliferation of the Response Types registry. Which is kind of ugly but something that no one will care much about once it's done. It's also more of a
consequence of the response type constructs put forth by OAuth than it is with this particular extension.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<br>
Brian<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
[1] <a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html" target="_blank">
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html</a><br>
<br>
<br>
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
<br>
<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br>
</div></div>