<p dir="ltr">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 class="gmail_quote">On Oct 18, 2013 1:49 AM, "Vladimir Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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><br>
</blockquote></div>