<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:Verdana;
        panose-1:2 11 6 4 3 5 4 4 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";}
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";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m not sure I understand what you’re saying about error responses, Breno. 
<a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html#MultiValueResponseTypes">
http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html#MultiValueResponseTypes</a> says:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:48.0pt;mso-margin-bottom-alt:auto;margin-left:48.0pt">
<span lang="EN" style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:black">The all parameters returned from the Authorization Endpoint SHOULD use the same Response Encoding. This recommendation applies to
<span style="background:yellow;mso-highlight:yellow">both success and error responses</span>.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I suppose we could be even more explicit by saying that both successful and error responses use the specified response encoding, or if none is supplied, the
 default response encoding.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Would that address your comment?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">                                                            -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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""> Breno de Medeiros [mailto:breno@google.com]
<br>
<b>Sent:</b> Friday, October 18, 2013 5:43 AM<br>
<b>To:</b> Vladimir Dzhuvinov / NimbusDS<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net; Mike Jones<br>
<b>Subject:</b> Re: [Openid-specs-ab] proposed POST response type for OAuth/Connect<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<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. <o:p></o:p></p>
<div>
<p class="MsoNormal">On Oct 18, 2013 1:49 AM, "Vladimir Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>> wrote:<o:p></o:p></p>
<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 href="http://www.NimbusDS.com" target="_blank">www.NimbusDS.com</a> :
<a href="mailto:vladimir@nimbusds.com">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 href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
Date: Fri, October 18, 2013 8:02 am<br>
To: "<<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>"<br>
<<a href="mailto:openid-specs-ab@lists.openid.net">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 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 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 href="mailto:breno@google.com">breno@google.com</a>]<br>
 Sent: Thursday, October 17, 2013 4:02 PM<br>
 To: Mike Jones<br>
 Cc: Brian Campbell; <<a href="mailto:openid-specs-ab@lists.openid.net">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 href="mailto:Michael.Jones@microsoft.com">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 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 href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br>
[mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">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 href="mailto:openid-specs-ab@lists.openid.net">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 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 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>
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><o:p></o:p></p>
</div>
</div>
</body>
</html>