<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://5149/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I am OK with response_mode or response_encoding.<div><br></div><div>John B.</div><div><br><div><div>On 2013-10-18, at 12:46 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">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?<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">If I don’t hear objections or alternative suggestions, I’ll change to using that.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span>Breno de Medeiros [mailto:breno@<a href="http://google.com">google.com</a>]<span class="Apple-converted-space"> </span><br><b>Sent:</b><span class="Apple-converted-space"> </span>Friday, October 18, 2013 5:48 AM<br><b>To:</b><span class="Apple-converted-space"> </span>Vladimir Dzhuvinov / NimbusDS<br><b>Cc:</b><span class="Apple-converted-space"> </span>Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [Openid-specs-ab] proposed POST response type for OAuth/Connect<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">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.<o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">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.<o:p></o:p></p><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On Oct 18, 2013 5:42 AM, "Breno de Medeiros" <<a href="mailto:breno@google.com" style="color: purple; text-decoration: underline; ">breno@google.com</a>> wrote:<o:p></o:p></div><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">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><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On Oct 18, 2013 1:49 AM, "Vladimir Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com" target="_blank" style="color: purple; text-decoration: underline; ">vladimir@nimbusds.com</a>> wrote:<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">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 :<span class="Apple-converted-space"> </span><a href="http://www.NimbusDS.com" target="_blank" style="color: purple; text-decoration: underline; ">www.NimbusDS.com</a><span class="Apple-converted-space"> </span>:<span class="Apple-converted-space"> </span><a href="mailto:vladimir@nimbusds.com" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">openid-specs-ab@lists.openid.net</a>>"<br><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" style="color: purple; text-decoration: underline; ">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" style="color: purple; text-decoration: underline; ">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" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">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" style="color: purple; text-decoration: underline; ">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:<span class="Apple-converted-space"> </span><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank" style="color: purple; text-decoration: underline; ">openid-specs-ab-bounces@lists.openid.net</a><br>[mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">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" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" style="color: purple; text-decoration: underline; ">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" target="_blank" style="color: purple; text-decoration: underline; ">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" style="color: purple; text-decoration: underline; ">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></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</div></blockquote></div><br></div></body></html>