<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Torsten,<div><br></div><div>This is not really about the code response type. (Though it might be observed that code to a public client would be safer with POST than GET as the code would not leak in the referrer)</div><div><br></div><div>The issue is with the "code id_token", "token id_token", "code token id_token" and "id_token" response types where the recipient is not JS in the browser but a host.</div><div><br></div><div>The "code id_token" response type was intended to give the client a fast way to customize the UI while it asynchronously fetches additional data in the back end.</div><div><br></div><div>Currently the redirect_uri must contain JS that parses the fragment and sends the contents of the fragment as a form encoded POST to the client.</div><div><br></div><div>Some people want to optimize that by having the Authorization server send JS that autoposts a form with the paramaters like openID 2.</div><div><br></div><div>There might be a alight speed advantage, but the main advantage is a simpler client (you will now point out that simple clients should use code).</div><div><br></div><div>The downside to POST in a redirect is well understood as having sub-optimal UI with browser flashing and possibly needing to present a submit button as compared to postMessage or fragment encoding.</div><div><br></div><div>My personal feeling is that this is a OAuth issue, though one that impacts Connect. </div><div><br></div><div>My main concern is forcing something through in Connect may not align with a OAuth WG is that it will require more work for implementers in the long run.</div><div><br></div><div>There is nothing in the current spec that is any way unworkable, however using POST can be a useful optimization in some specific environments.</div><div><br></div><div>I suspect that this is partially a fragment encoding is new and unfamiliar while POST is well understood by developers issue. </div><div>If everyone moved from fragment to POST for Connect it would not be a positive UI direction.</div><div><br></div><div>I have not totally made my mind up yet, but am leaning towards this being a OAuth extension rather than something specific to Connect.</div><div><br></div><div>John B.</div><div><br><div><div>On 2013-10-17, at 6:19 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</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">
Hi all,<br>
<br>
can someone please explain the problems, which shall be resolved by
POSTing responses? As far as I understand, POSTing responses in
OpenID 2.0 were neccessary in order to transport large amounts of
data (esp. when utilizing AX). In OAuth and Connect, there is just
the authz code + state sent to the client in the grant type code. I
don't expect them to blow up the redirect URI.<br>
<br>
regards,<br>
Torsten. <br>
<br>
<div class="moz-cite-prefix">Am 17.10.2013 22:38, schrieb Richer,
Justin P.:<br>
</div>
<blockquote cite="mid:B33BFB58CCC8BE4998958016839DE27E33BDF16D@IMCMBX01.MITRE.ORG" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
span.EmailStyle17
{font-family:"Calibri","sans-serif";
color:#1F497D}
.MsoChpDefault
{font-family:"Calibri","sans-serif"}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
-->
</style>
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr; font-family: Tahoma; font-size: 10pt; ">I completely agree with Nat. There
have been many months for people to comment on, interop with,
and add features to the set. I think that changing something
this fundamental this late in the game with so little testing
behind it is ludicrous. I don't understand how this is coming up
all of a sudden. From my perspective, it sounds like one
contingent is trying to sneak something in just under the wire
and hoping nobody will notice.
<br>
<br>
This can easily be defined as an extension and it would do much
more harm than good trying to cram it in now.<br>
<br>
As to Tony's contention: plenty of us are deploying and exactly
what you keep calling impossible. There are numerous existence
proofs in contrast to your position.<br>
<br>
-- Justin<br>
<br>
<div style="font-family: 'Times New Roman'; font-size: 16px; ">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF193203"><font size="2" face="Tahoma"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>] on behalf of
Anthony Nadalin [<a class="moz-txt-link-abbreviated" href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>]<br>
<b>Sent:</b> Thursday, October 17, 2013 2:04 PM<br>
<b>To:</b> Nat Sakimura; Mike Jones<br>
<b>Cc:</b> <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] Spec call notes
17-Oct-13<br>
</font><br>
</div>
<div>
<div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">If you can’t deploy this stuff it’s no
good, it would then be a board issue to approve or
disapprove and I know where I would vote</span></p><p class="MsoNormal"><a moz-do-not-send="true" name="_MailEndCompose"><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span></a></p><p class="MsoNormal"><b><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif"">
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Nat Sakimura<br>
<b>Sent:</b> Thursday, October 17, 2013 9:55 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> <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] Spec call notes
17-Oct-13</span></p><div> <br class="webkit-block-placeholder"></div>
<div><p class="MsoNormal">I completely disagree. We have
feature frozen months ago and we should not allow any
feature bloat now. We have decided it and we must
adhere to it. </p>
<div>
<div><p class="MsoNormal">It is a process and trust
issue. Also, the timing is critical for several
things that you probably have already heard. </p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">If it could not be done with an
extension, I would be more sympathetic. However,
in this case, you can do it as an extension, and
that is still conformant once that extension gets
voted. The core does not prohibit it. </p>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">And do not mix up Google's
postMessage and Form encoding + POSTing. </p>
</div>
<div><p class="MsoNormal">The fragment encoding was
supposed to be used with postMessage and that's
what Google is doing. </p>
</div>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">Even if you had the new feature
text on Monday, there is not enough review
period. </p>
</div>
<div><p class="MsoNormal">Also, note that the Monday
meeting has no authority to decide on such things.
It has to be done in the list, and we have to give
ample time to respond. </p>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">We MUST NOT push any new
feature through so quickly. </p>
</div>
</div>
<div><div> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal">Sorry to be a process police
here, but that's what I have to do as a chair. </p>
</div>
</div>
<div><div style="margin-bottom: 12pt; "> <br class="webkit-block-placeholder"></div>
<div><p class="MsoNormal">2013/10/18 Mike Jones <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></p>
<blockquote style="border:none; border-left:solid
#CCCCCC 1.0pt; padding:0in 0in 0in 6.0pt;
margin-left:4.8pt; margin-right:0in">
<div>
<div><p class="MsoNormal" style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">I actually think that getting
the features right, such that developers
will actually use what’s in the spec, rather
than do something non-conformant, is more
important than a few days of schedule.</span></p><div style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">It’s pretty telling that
Google, Ping, and Microsoft all are using
something other than fragment encoding in
some cases for Implicit/Hybrid flows. Far
better to enable interop on these
non-fragment return types than have everyone
do something outside the spec.</span></p><div style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">As we said on the call, I’ll
write up a concrete proposal so people can
review it in advance of Monday.</span></p><div style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">Yes, we’re late in the
process, but far better to make a late
addition than to ship something that we know
has defects that will cause people to do
things not in the spec.</span></p><div style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D">
-- Mike</span></p><div style=""><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:#1F497D"> </span><br class="webkit-block-placeholder"></div><p class="MsoNormal" style=""><b><span style="font-size:10.0pt;
font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;
font-family:"Tahoma","sans-serif"">
Nat Sakimura [mailto:<a moz-do-not-send="true" href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, October 17, 2013 9:19
AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> <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] Spec
call notes 17-Oct-13</span></p>
<div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
<div><p class="MsoNormal" style="">Please add
to the note that Nat has pointed out
that this is not the time to add a new
feature that it can and should be dealt
with extension. </p>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">Also, John
has pointed out that expanding the
feature will cause interoperability
problems. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">As part of
the AOL's OpenID 2.0 provider
explanation, it was pointed out that
the UI would show flash and button,
and that was the reason we have
dropped it from the current Connect
spec. </p>
</div>
<div><p class="MsoNormal" style="">In fact,
not only AOL but many others did it in
OpenID 2.0 as that was the only
option, and it was also something that
many of us wanted to escape from. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">The reason
sited in support of form POSTing were
as follows: </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">1) It is
done by SAML and WS. </p>
</div>
<div><p class="MsoNormal" style="">2)
Fragment would not be able to hold
large payload. </p>
</div>
<div><p class="MsoNormal" style="">3) If it
is not there, implementers will do
stupid things like including access
token in the query parameter. </p>
</div>
<div><p class="MsoNormal" style="">4) If the
browser is not Javascript enabled, it
is the last resort. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">In the
above, 1) does not make sense. The web
technology has advanced so much since
they were designed. We have considered
the option previously and dropped. </p>
</div>
<div><p class="MsoNormal" style="">As to 2)
is concerned, the statement is false.
Fragment can hold pretty big payload.
It was tested during the self-issued
testing, and we found out that the
limit is actually pretty large. We
were sending photos as a claim in
id_token as a result of it. (Note: I
need to double check - since we were
concerned mostly on mobile platform,
we may not have tested IE.) </p>
</div>
<div><p class="MsoNormal" style="">The reason
3) is not a good one either. We should
just write an implementers NOTE that
they should never do this. </p>
</div>
<div><p class="MsoNormal" style="">As a
result, only the credible reason is
4). However, this means that a lot of
other things at the destination site
will break, too. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">I
understand that there are people who
want to do it. </p>
</div>
<div><p class="MsoNormal" style="">Even some
of NRI's internal developers wants to
do it. </p>
</div>
<div><p class="MsoNormal" style="">However,
that is not a good enough reason to
get it into the core at this point in
time. </p>
</div>
<div><p class="MsoNormal" style="">In
addition, there will be bunch of
moving parts that we have to fix if we
were to do it. </p>
</div>
<div><p class="MsoNormal" style="">We should
not do it in three days. We should
take more time to consider various
implications. </p>
</div>
<div><p class="MsoNormal" style="">We are
finalizing the core spec now. The cut
off date is end of this week. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
<div><p class="MsoNormal" style="">It should
be done as an extension. I oppose to
do it in the core. </p>
</div>
<div><p class="MsoNormal" style="">Our
priority to get the Core out of the
door, now. </p>
</div>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div>
</div>
<div><div style="margin-bottom: 12pt; "> <br class="webkit-block-placeholder"></div>
<div><p class="MsoNormal" style="">2013/10/17
Mike Jones <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></p>
<div>
<div><p class="MsoNormal" style="">Spec
call notes 17-Oct-13</p><div style=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="">Mike
Jones</p><p class="MsoNormal" style="">Brian
Campbell</p><p class="MsoNormal" style="">George
Fletcher</p><p class="MsoNormal" style="">John
Bradley</p><p class="MsoNormal" style="">Nat
Sakimura</p><p class="MsoNormal" style="">Edmund
Jay</p><div style=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="">Agenda:</p><p class="MsoNormal" style="">
Open Issues</p><p class="MsoNormal" style="">
Multiple response type requests
returning values in ways other
than fragments</p><p class="MsoNormal" style="">
Document Restructuring and Review</p><div style=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="">Open
Issues:</p><p class="MsoNormal" style="">
#873: session 4.1. Can we use opbs
with http (not httponly)</p><p class="MsoNormal" style="">
We developed proposed text for
this</p><p class="MsoNormal" style="">
#879 & #880: Hosting <a moz-do-not-send="true" href="http://self-issued.me/" target="_blank">
self-issued.me</a></p><p class="MsoNormal" style="">
John will get the cheapest Amazon
VM and give Edmund access to it</p><div style=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="">Multiple
response type requests returning
values in ways other than
fragments</p><p class="MsoNormal" style="">
Microsoft has asked for a POST
binding, like WS-Federation and
SAML have</p><p class="MsoNormal" style="">
Ping has an extra response_type
component x_post</p><p class="MsoNormal" style="">
This causes the responses to POST
to be returned as form-encoded
body content</p><p class="MsoNormal" style="">
Google has a way of registering
clients to use a postMessage
binding</p><p class="MsoNormal" style="">
They do that by registering a
JavaScript origin, rather than
response_type</p><p class="MsoNormal" style="">
AOL's OpenID 2.0 provider often
uses the POST response because of
large AX responses</p><p class="MsoNormal" style="">
John had proposed a registration
parameter for this:</p><p class="MsoNormal" style="">
redirect_type fragment | POST |
postMessage</p><p class="MsoNormal" style="">
This would be discoverable as</p><p class="MsoNormal" style="">
redirect_types_supported</p><p class="MsoNormal" style="">
Another reason for this is to not
hit fragment size limits</p><p class="MsoNormal" style="">
Mike will file a bug on this to
make a concrete proposal</p><p class="MsoNormal" style="">
We will discuss this at the Monday
meeting</p><div style=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal" style="">Document
Restructuring and Review:</p><p class="MsoNormal" style="">
Mike posted a Word version of the
Core spec with tracked changes
turned on</p><p class="MsoNormal" style="">
People are requested to mark it up
with specific proposed changes
this week</p>
</div>
</div><p class="MsoNormal" style="margin-bottom:12.0pt"><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>
</div><p class="MsoNormal" style=""><br>
<br clear="all">
</p>
<div><div style=""> <br class="webkit-block-placeholder"></div>
</div><p class="MsoNormal" style="">-- <br>
Nat Sakimura (=nat)</p>
<div><p class="MsoNormal" style="">Chairman,
OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div><p class="MsoNormal"><br>
<br clear="all">
</p>
<div><div> <br class="webkit-block-placeholder"></div>
</div><p class="MsoNormal">-- <br>
Nat Sakimura (=nat)</p>
<div><p class="MsoNormal">Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</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>
</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></body></html>