<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8" /><meta http-equiv="content-type" content="text/html; charset=utf-8" /><meta http-equiv="Content-Type" content="text/html;
charset=ISO-2022-JP" /><meta name="Generator" content="Microsoft Word 14 (filtered
medium)" /><style><!--
/* Font Definitions */
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 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";
color:black;}
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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.nx
{mso-style-name:nx;}
span.o
{mso-style-name:o;}
span.kd
{mso-style-name:kd;}
span.p
{mso-style-name:p;}
span.c1
{mso-style-name:c1;}
span.s2
{mso-style-name:s2;}
span.k
{mso-style-name:k;}
span.EmailStyle27
{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";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">+1<br><br><div class="gmail_quote"><br>
<br>
John Bradley <ve7jtb@ve7jtb.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I recall that the requirement for TLS if used for authentication was a later addition to the OAuth spec.<div><br /></div><div>It probably is sufficient, however it may not be a bad Idea to always make it TLS for form_post to avoid confusion by developers.</div><div><br /></div><div>John B.<br /><div><div>On 2013-10-19, at 5:21 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline" /><blockquote type="cite"><div dir="auto"><div>Hi George,</div><blockquote type="cite"><font face="Helvetica, Arial, sans-serif">
<br />
Another thought, do we have to explicitly require that if the
html_form response_mode is used, then the redirect_url MUST have a
scheme of https? If the initial request is from a 'confidential'
client then OAuth2 and OpenID Connect allow the redirect_url to be
http.<br /></font></blockquote><div><br /></div>How did you come to this conclusion? OAuth requires clients using the authorization response data for authentication purposes to use HTTPS.<div><br /></div><div><a href="http://tools.ietf.org/html/rfc6749#section-10.5"></a><div><a href="http://tools.ietf.org/html/rfc6749#section-10.5"></a><a href="http://tools.ietf.org/html/rfc6749#section-10.5"></a><div><a href="http://tools.ietf.org/html/rfc6749#section-10.5"></a><a href="http://tools.ietf.org/html/rfc6749#section-10.5">http://tools.ietf.org/html/rfc6749#section-10.5</a></div></div><div>
</div><div><br /></div><div>
</div><div>"Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process. Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS."</div><div><br /></div><div>regards,</div><div>Torsten.<br /><div><br /><blockquote type="cite"><font face="Helvetica, Arial, sans-serif">
<br />
Given the above, I have some concerns that by trying to rush the
additions into the specs we are going to miss something important.<br />
<br />
Thanks,<br />
George<br />
<br />
</font>
<div class="moz-cite-prefix">On 10/18/13 2:00 PM, Mike Jones wrote:<br />
</div>
<blockquote cite="mid:4E1F6AAD24975D4BA5B168042967394377E046E6@TK5EX14MBXC286.redmond.corp.microsoft.com" type="cite">
<!--[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]-->
<div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Or
possibly “form_POST”? What do others think?<p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’ve
updated Discovery to add proposed text for the
“response_modes_supported” parameter. See:<p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<a moz-do-not-send="true" href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html">http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html</a><p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<a moz-do-not-send="true" href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx">http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx</a><p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I
also updated the Multiple Response Types drafts posted to
specify the encoding for the POST response, as Breno
suggested.<p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’ll
finish the updates to Core to update the normative text that
currently requires fragment encoding Implicit and Hybrid
response parameters when I get back from an appointment in a
few hours.<p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
-- Mike<p></p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
n-sakimura [<a class="moz-txt-link-freetext" href="mailto:n-sakimura@nri.co.jp">mailto:n-sakimura@nri.co.jp</a>]
<br />
<b>Sent:</b> Friday, October 18, 2013 10:49 AM<br />
<b>To:</b> Mike Jones<br />
<b>Cc:</b> Breno de Medeiros; John Bradley;
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br />
<b>Subject:</b> Re: [Openid-specs-ab] proposed POST
response type for OAuth/Connect<p></p></span></p>
</div>
</div><p class="MsoNormal"></p><p> </p>
<div><p class="MsoNormal">POST is a misleading name for the
response mode / response encoding.
<br />
<br />
Even with fragment, one could potentially use POST. In fact,
that would be one of the easiest implementation choice for
the fragment encoding case: it is just a few lines of
Javascript code, such as:<br />
<br />
<br />
</p><p></p>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="nx">RelayToken</span><span class="o">:</span> </span><span class="kd"><span style="font-size:9.0pt;color:#004080">function</span></span><span style="font-size:9.0pt;color:#333333"> <span class="p">(</span><span class="nx">url</span><span class="p">,</span><span class="nx">callback</span><span class="p">)</span> <span class="p">{</span><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> </span><span class="c1"><i><span style="font-size:9.0pt;color:#999988">// calllback proto = function(data){ .... } </span></i></span><span style="font-size:9.0pt;color:#333333"><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="nx">token</span> <span class="o">=</span> <span class="nx">$</span><span class="p">.</span><span class="nx">FVAR</span><span class="p">(</span></span><span class="s2"><span style="font-size:9.0pt;color:#BB8844">"token"</span></span><span class="p"><span style="font-size:9.0pt;color:#333333">);</span></span><span style="font-size:9.0pt;color:#333333"><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="nx">state</span> <span class="o">=</span> <span class="nx">$</span><span class="p">.</span><span class="nx">FVAR</span><span class="p">(</span></span><span class="s2"><span style="font-size:9.0pt;color:#BB8844">"state"</span></span><span class="p"><span style="font-size:9.0pt;color:#333333">)</span></span><span style="font-size:9.0pt;color:#333333"><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> </span><span class="k"><span style="font-size:9.0pt;color:#004080">if</span></span><span style="font-size:9.0pt;color:#333333"> <span class="p">(</span><span class="nx">token</span><span class="p">)</span> <span class="p">{</span><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="nx">$</span><span class="p">.</span><span class="nx">post</span><span class="p">(</span><span class="nx">url</span><span class="p">,</span> <span class="p">{</span> <span class="nx">token</span><span class="o">:</span> <span class="nx">token</span><span class="p">,</span> <span class="nx">state</span><span class="o">:</span> <span class="nx">state</span> <span class="p">}).</span><span class="nx">done</span><span class="p">(</span><span class="nx">callback</span><span class="p">);</span><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="p">}</span><p></p></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span class="p">}</span><p></p></span></pre><p class="MsoNormal"> <br />
<br />
What you are describing as POST in fact is the
representation of the authorization grant in HTML Form. So,
instead of POST, 'html_form' or simply 'html' is a more
approriate description.
<br />
<br />
(2013/10/19 1:22), Mike Jones wrote:</p><p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">These
versions are updated to use Response Mode and to be more
explicit about always using the specified response mode,
including for errors:</p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">
<a moz-do-not-send="true" href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html</a></p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">
<a moz-do-not-send="true" href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx</a></p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Breno,
you’re right that you shouldn’t try to use POST or other
non-default response modes if you haven’t first verified
that the server supports it.</p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">
-- Mike</p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b>
Breno de Medeiros [<a moz-do-not-send="true" href="mailto:breno@google.com">mailto:breno@google.com</a>]
<br />
<b>Sent:</b> Friday, October 18, 2013 9:18 AM<br />
<b>To:</b> John Bradley<br />
<b>Cc:</b> Mike Jones; Vladimir Dzhuvinov / NimbusDS; <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a><br />
<b>Subject:</b> Re: [Openid-specs-ab] proposed POST
response type for OAuth/Connect</p><p></p><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p><p>I meant errors for unsupported response_mode (I don't
think encoding is a good name even for POST since encoding
would be x-www-form-urlencoded, not POST)</p><p></p>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Oct 18, 2013 9:15 AM, "Breno de Medeiros" <<a moz-do-not-send="true" href="mailto:breno@google.com">breno@google.com</a>>
wrote:</p><p></p><p>I agree w/ Mike that the sensible way to return error
responses should stay in default encoding for backward
compatibility. I am pointing out that if a client asks
for POST encoding and gets a fragment encoded error
response it will likely not be able to parse it. Since
the state parameter in particular will be missing it is
difficult to see how clients would recover.</p><p></p><p>So if POST is not MTI the client should establish ahead
of time that the IDP is compliant via discovery or other
means. It cannot rely on automatically recovering by
handling an error message. Which may be obvious but I am
just pointing out.</p><p></p>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Oct 18, 2013 8:50 AM, "John Bradley" <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>
wrote:</p><p></p>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I
am OK with response_mode or response_encoding.</p><p></p>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">John
B.</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
<div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
2013-10-18, at 12:46 PM, Mike Jones <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>
wrote:</p><p></p>
</div><p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"></p><p> </p>
<div>
<div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’m
flexible on the parameter name. I didn’t
use “transport” or “response_transport”
because it didn’t read as well as
“response_encoding”, but I hear what
you’re saying about postMessage and CORS
not really being encodings. I think I
like your “response_mode” suggestion the
best. What do others think?</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If
I don’t hear objections or alternative
suggestions, I’ll change to using that.</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">
-- Mike</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Breno
de Medeiros [mailto:<a moz-do-not-send="true" href="mailto:breno@" target="_blank">breno@</a><a moz-do-not-send="true" href="http://google.com/" target="_blank">google.com</a>] <br />
<b>Sent:</b> Friday, October 18, 2013 5:48
AM<br />
<b>To:</b> Vladimir Dzhuvinov / NimbusDS<br />
<b>Cc:</b> Mike Jones; <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">
openid-specs-ab@lists.openid.net</a><br />
<b>Subject:</b> Re: [Openid-specs-ab]
proposed POST response type for
OAuth/Connect</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div><p>I mean when server cannot support specified
encoding. I am skeptical we can provide a
backwards compatible solution though I am
not sure one is needed if MTI is only the
default.</p><p></p><p>I would prefer response_transport or
response_mode instead of encoding since
neither POST, postMessage, or CORS (to
mention future candidates) feel like
alternative encodings. They are really more
than that.</p><p></p>
<div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Oct 18, 2013 5:42 AM, "Breno de
Medeiros" <<a moz-do-not-send="true" href="mailto:breno@google.com" target="_blank">breno@google.com</a>>
wrote:</p><p></p>
</div><p>The main issue I see here is that error
messages no longer feel right being
supplied in the default encoding for type.
Case in point: if client requests POST
because it wants ID_token but can't parse
fragments, returning a fragment-encoded
response will not help the caller.</p><p></p>
<div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Oct 18, 2013 1:49 AM, "Vladimir
Dzhuvinov / NimbusDS" <<a moz-do-not-send="true" href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a>>
wrote:</p><p></p>
</div>
<div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Mike, hi guys,<br />
<br />
I read the proposed spec and it looks
good to me. Making the "what" and<br />
the "how" orthogonal parameters is
great.<br />
<br />
Vladimir<br />
<br />
--<br />
Vladimir Dzhuvinov : <a moz-do-not-send="true" href="http://www.nimbusds.com/" target="_blank">www.NimbusDS.com</a> : <a moz-do-not-send="true" href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a><br />
<br />
<br />
<br />
<br />
-------- Original Message --------<br />
Subject: Re: [Openid-specs-ab]
proposed POST response type for<br />
OAuth/Connect<br />
From: Mike Jones <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br />
Date: Fri, October 18, 2013 8:02 am<br />
To: "<<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>"<br />
<<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br />
<br />
As Breno suggested, I’ve made the
proposed changes to the Multiple<br />
Response Types spec. These changes do
two things:<br />
1. Disentangle the specification
of what parameters are to be<br />
returned (which is done with the
response_type parameter) from the<br />
specification of how they are to be
returned (which is done with the<br />
response_encoding parameter).<br />
2. Define a POST response
encoding that can be used to request<br />
that parameters be returned via form
POST.<br />
<br />
The response_encoding parameter is
only used when a non-default<br />
encoding is requested, so these
changes will no effect on current<br />
implementations.<br />
<br />
I’ve posted an updated version at<br />
<a moz-do-not-send="true" href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html</a>.<br />
The .xml source is posted there as
well. Also, diffs from the current<br />
BitBucket version can be viewed as
tracked changes in the Word version<br />
at<br />
<a moz-do-not-send="true" href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx</a>.<br />
<br />
Tomorrow I’ll review the current
Connect specs and make the following<br />
related proposed changes:<br />
· Add the
response_encodings_supported discovery
parameter.<br />
· Review the places where
fragment encoding is explicitly or<br />
implicitly specified, making sure the
language doesn’t prohibit using<br />
the POST response encoding instead.
(Note that we should do this now,<br />
even should we don’t adopt POST as
part of the core now, so we don’t<br />
preclude it in the future.)<br />
(I’d make these changes now, but it’s
probably better that I do it<br />
when I’m not tired.)<br />
<br />
Anyway, this wasn’t hard and the
result isn’t difficult to<br />
understand or implement. (And
implementation will remain optional.)<br />
<br />
Thanks to Breno, John, and Brian for
the feedback on how this should<br />
work. Thanks especially to Brian for
posting his draft, which I<br />
borrowed some text and the example
from.<br />
<br />
-- Mike<br />
<br />
From: Breno de Medeiros [mailto:<a moz-do-not-send="true" href="mailto:breno@google.com" target="_blank">breno@google.com</a>]<br />
Sent: Thursday, October 17, 2013 4:02
PM<br />
To: Mike Jones<br />
Cc: Brian Campbell; <<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br />
Subject: Re: [Openid-specs-ab]
proposed POST response type for<br />
OAuth/Connect<br />
<br />
<br />
<br />
On Thu, Oct 17, 2013 at 11:37 AM,
Mike Jones<br />
<<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>
wrote:<br />
Thanks, Brian. This is really
useful. I suspect I’ll be using<br />
some of your text in my write-up. J<br />
<br />
I just spent some time on the phone
with Breno discussing this and he<br />
agreed that defining a POST response
at this point is reasonable. When<br />
talking about possible ways of
specifying the POST response behavior,
he<br />
stated the principle that when a
behavioral change is being requested,<br />
that this should be done so
dynamically, rather than via
registration.<br />
That way, particular clients can be
updated to use this behavior without<br />
requiring a new client registration.
(He likes using registration to<br />
specify behavioral restrictions,
however, such as requiring particular<br />
signing/encryption algorithms, etc.)<br />
<br />
He said that the way that he’d do it
is to include a<br />
“transport=POST” parameter in the
authorization request. So<br />
that’s what I’ll write up. We could
later than define<br />
“transport=postMessage”,
“transport=CORS”, etc. if we decide to<br />
do so.<br />
<br />
<br />
<br />
<br />
I think this is sufficiently small
that we might be able to undertake in<br />
a short time-frame. I believe that
POST support will prove useful. I'd<br />
recommend this to be added to the new
response types part of the spec:<br />
<a moz-do-not-send="true" href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html" target="_blank">http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html</a>,<br />
for a number of reasons: It already
has the burden to deal with the<br />
security properties of different
encoding formats for different
response<br />
types, and would be a small change in
scope to change it to talk about<br />
'transport' modes instead of encoding.
That spec also has been stable<br />
and changed little for a long time, so
the chance that it can be<br />
re-written w/o side-effects is
probably higher.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
As an aside, Breno also said that the
reason that he thinks Session<br />
Management isn’t yet ready to be
final, is that he’d like us to<br />
explore the option of using a CORS
transport, rather than postMessage<br />
within Session Management. I’ll leave
it to Breno to say more about<br />
this.<br />
<br />
Thanks<br />
all,<br />
-- Mike<br />
<br />
From: <a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br />
[mailto:<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
On Behalf Of Brian<br />
Campbell<br />
Sent: Thursday, October 17, 2013 8:56
AM<br />
To: <<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br />
Subject: [Openid-specs-ab] proposed
POST response type for<br />
OAuth/Connect<br />
<br />
As discussed during today's call
[1], attached is the<br />
pseudo-standard document I wrote up
earlier this year describing an HTTP<br />
POST response type (effectively a POST
binding) for OAuth/OIDC.<br />
<br />
I know everyone has a lot of docs to
read right now but this one is<br />
*very* short and has a good example.<br />
<br />
We've found this approach to work well
in practice and be easy to<br />
implement.<br />
<br />
It can be done as a straight
extension, as illustrated with this
doc, or<br />
could incorporated into core connect.<br />
<br />
<br />
<br />
As John mentioned, the main drawback
of this approach is proliferation<br />
of the Response Types registry. Which
is kind of ugly but something that<br />
no one will care much about once it's
done. It's also more of a<br />
consequence of the response type
constructs put forth by OAuth than it<br />
is with this particular extension.<br />
<br />
Thanks,<br />
Brian<br />
<br />
<br />
[1]<br />
<a moz-do-not-send="true" 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 />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
--<br />
--Breno<br />
<br />
<br />
<br />
_______________________________________________<br />
Openid-specs-ab mailing list<br />
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br />
<a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br />
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p><p></p>
</div>
</div>
</div>
</div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br />
Openid-specs-ab mailing list<br />
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br />
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p><p></p>
</div>
</div><p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p><p></p>
</div>
</div>
</div>
</div>
</div><p class="MsoNormal"><br />
<br />
<br />
</p><p></p>
<pre>_______________________________________________<p></p></pre>
<pre>Openid-specs-ab mailing list<p></p></pre>
<pre><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><p></p></pre>
<pre><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><p></p></pre>
</blockquote><p class="MsoNormal"><br />
<br />
<br />
</p><p></p>
<pre>-- <p></p></pre>
<pre>Nat Sakimura (<a moz-do-not-send="true" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)<p></p></pre>
<pre>Nomura Research Institute, Ltd. <p></p></pre>
<pre><a moz-do-not-send="true" href="tel:+81-3-6274-1412">Tel:+81-3-6274-1412</a> Fax:+81-3-6274-1547<p></p></pre>
<pre><p> </p></pre>
<pre><span style="font-family:"MS Gothic"">本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ</span>ӓ<p></p></pre>
<pre> 6;|<p></p></pre>
<pre>14;<span style="font-family:"MS Gothic"">せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。</span><p></p></pre>
<pre>PLEASE READ:<p></p></pre>
<pre>The information contained in this e-mail is confidential and intended for the named recipient(s) only.<p></p></pre>
<pre>If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.<p></p></pre>
</div>
<br />
<fieldset class="mimeAttachmentHeader"></fieldset>
<br />
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br />
<div class="moz-signature">-- <br />
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me"><XeC></a></div>
</blockquote><blockquote type="cite"><span>_______________________________________________</span><br /><span>Openid-specs-ab mailing list</span><br /><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br /><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br /></blockquote></div></div></div></div>_______________________________________________<br />Openid-specs-ab mailing list<br /><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br />http://lists.openid.net/mailman/listinfo/openid-specs-ab<br /></blockquote></div><br /></div></blockquote></div></body></html>