<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes POST is a option for fragment encoding for certain browsers that don't support fragments in the location header, but it is still using fragment encoding.<div><br></div><div>So yes the key thing is that the parameters are form encoded on a POST rather than being fragment encoded, requiring clients side JS to parse them and POST Them to a endpoint.</div><div><br></div><div>Thinking about it, any client that is a server that wants the parameters needs to have a endpoint that can take the parameters as a form-encoded post anyway, so using the same endpoint for the html_post directly from the AS should not be a big deal for them. </div><div><br></div><div>John B.</div><div><br></div><div><div><div>On 2013-10-18, at 2:49 PM, n-sakimura <<a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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>
<pre style="font-family: 'Bitstream Vera Sans Mono', 'DejaVu Sans Mono', Monaco, monospace; font-size: 12px; line-height: 1.4000000000000001; margin: 0px; padding: 0px; color: rgb(51, 51, 51); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"> <span class="nx">RelayToken</span><span class="o">:</span> <span class="kd" style="color: rgb(0, 64, 128);">function</span> <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>
<span class="c1" style="color: rgb(153, 153, 136); font-style: italic;">// calllback proto = function(data){ .... } </span>
<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 class="s2" style="color: rgb(187, 136, 68);">"token"</span><span class="p">);</span>
<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 class="s2" style="color: rgb(187, 136, 68);">"state"</span><span class="p">)</span>
<span class="k" style="color: rgb(0, 64, 128);">if</span> <span class="p">(</span><span class="nx">token</span><span class="p">)</span> <span class="p">{</span>
<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>
<span class="p">}</span>
<span class="p">}</span></pre>
<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:<br>
</div>
<blockquote cite="mid:4E1F6AAD24975D4BA5B168042967394377E030AB@TK5EX14MBXC286.redmond.corp.microsoft.com" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<div class="WordSection1"><p class="MsoNormal"><span>These versions are updated to use
Response Mode and to be more explicit about always using the
specified response mode, including for errors:</span></p><p class="MsoNormal"><span>
<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></span></p><p class="MsoNormal"><span>
<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></span></p><div><span> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span>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.</span></p><div><span> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><span>
-- Mike</span></p><div><span> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal"><b>From:</b><span> Breno de
Medeiros [<a class="moz-txt-link-freetext" 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 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</span></p><div> <br class="webkit-block-placeholder"></div><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>
<div><p class="MsoNormal">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>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>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>
<div><p class="MsoNormal">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>
<div><p class="MsoNormal">I am OK with response_mode or
response_encoding.</p>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">John B.</p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
<div>
<div><p class="MsoNormal">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>
</div><p class="MsoNormal"><br>
<br>
</p>
<div>
<div>
<div><p class="MsoNormal"><span>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?</span></p>
</div>
<div><div><span> </span><br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal"><span>If I don’t hear
objections or alternative suggestions, I’ll
change to using that.</span></p>
</div>
<div><div><span> </span><br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal"><span>
-- Mike</span></p>
</div>
<div><div><span> </span><br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal"><b>From:</b><span> 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</span></p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</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>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>
<div>
<div><p class="MsoNormal">On Oct 18, 2013 5:42 AM,
"Breno de Medeiros" <<a moz-do-not-send="true" href="mailto:breno@google.com" target="_blank"><span>breno@google.com</span></a>>
wrote:</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>
<div>
<div><p class="MsoNormal">On Oct 18, 2013 1:49
AM, "Vladimir Dzhuvinov / NimbusDS" <<a moz-do-not-send="true" href="mailto:vladimir@nimbusds.com" target="_blank"><span>vladimir@nimbusds.com</span></a>>
wrote:</p>
</div>
<div><p class="MsoNormal">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"><span>www.NimbusDS.com</span></a> : <a moz-do-not-send="true" href="mailto:vladimir@nimbusds.com" target="_blank"><span>vladimir@nimbusds.com</span></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"><span>Michael.Jones@microsoft.com</span></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"><span>openid-specs-ab@lists.openid.net</span></a>>"<br>
<<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><span>openid-specs-ab@lists.openid.net</span></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"><span>http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html</span></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"><span>http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx</span></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"><span>breno@google.com</span></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"><span>openid-specs-ab@lists.openid.net</span></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"><span>Michael.Jones@microsoft.com</span></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"><span>http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html</span></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"><span>openid-specs-ab-bounces@lists.openid.net</span></a><br>
[mailto:<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><span>openid-specs-ab-bounces@lists.openid.net</span></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"><span>openid-specs-ab@lists.openid.net</span></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"><span>http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html</span></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"><span>Openid-specs-ab@lists.openid.net</span></a><br>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><span>http://lists.openid.net/mailman/listinfo/openid-specs-ab</span></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"><span>Openid-specs-ab@lists.openid.net</span></a><br>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><span>http://lists.openid.net/mailman/listinfo/openid-specs-ab</span></a></p>
</div>
</div>
</div>
</div><p class="MsoNormal"><span>_______________________________________________<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></span></p>
</div>
</div><div> <br class="webkit-block-placeholder"></div>
</div>
</div>
</div>
</div>
</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>
<br>
<pre class="moz-signature" cols="72">--
Nat Sakimura (<a class="moz-txt-link-abbreviated" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
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.
</pre>
</div>
</blockquote></div><br></div></body></html>