[Openid-specs-ab] proposed POST response type for OAuth/Connect

George Fletcher gffletch at aol.com
Fri Oct 18 18:26:44 UTC 2013


I agree with Nat. While we call the flow a POST-redirect binding (and in
the OpenID2 case it more naturally fits this model), the response_mode
choices of query and fragment most naturally fit with html_form. The
mechanism used to submit the form is the POST-redirect mechanism.

As for the plan to address this in the specs, I'd prefer just describing
the response_mode parameter in it's optional state with the description
that additional response_modes can be added at a later time. Then do the
rest of the 'html_form' flow as an extension. This makes sure the specs
are extensible to others like postMessage and CORS while not adding
functionality to the current specs. This also ensures that OpenID
Connect Providers must understand the parameter name even if for now
they ignore it.

It also allows current implementations to continue with their
implementation without being out of compliance with the spec; meaning
they have an extension point for this functionality.

That said, with adding the new response_mode parameter, do we need to
add new text around things like what happens with the client sends
response_mode=query for an implicit request and the AS is not willing to
return the data in the query string? Is this an 6749 'invalid_request'
error or a 'unsupported_response_type'?

Another thought, do we have to explicitly require that if the html_form
response_mode is used, then the redirect_url MUST have a scheme of
https? If the initial request is from a 'confidential' client then
OAuth2 and OpenID Connect allow the redirect_url to be http.

Given the above, I have some concerns that by trying to rush the
additions into the specs we are going to miss something important.

Thanks,
George

On 10/18/13 2:00 PM, Mike Jones wrote:
>
> Or possibly “form_POST”? What do others think?
>
> I’ve updated Discovery to add proposed text for the
> “response_modes_supported” parameter. See:
>
> http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html
>
> http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx
>
> I also updated the Multiple Response Types drafts posted to specify
> the encoding for the POST response, as Breno suggested.
>
> I’ll finish the updates to Core to update the normative text that
> currently requires fragment encoding Implicit and Hybrid response
> parameters when I get back from an appointment in a few hours.
>
> -- Mike
>
> *From:*n-sakimura [mailto:n-sakimura at nri.co.jp]
> *Sent:* Friday, October 18, 2013 10:49 AM
> *To:* Mike Jones
> *Cc:* Breno de Medeiros; John Bradley; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] proposed POST response type for
> OAuth/Connect
>
> POST is a misleading name for the response mode / response encoding.
>
> 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:
>
>
>     RelayToken: function (url,callback) {
>         /// calllback proto = function(data){ .... } /
>         token = $.FVAR("token");
>         state = $.FVAR("state")
>         if (token) {
>             $.post(url, { token: token, state: state }).done(callback);
>         }
>     }
>
>
>
> 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.
>
> (2013/10/19 1:22), Mike Jones wrote:
>
>     These versions are updated to use Response Mode and to be more
>     explicit about always using the specified response mode, including
>     for errors:
>
>     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-diffs.docx
>
>     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.
>
>     -- Mike
>
>     *From:* Breno de Medeiros [mailto:breno at google.com]
>     *Sent:* Friday, October 18, 2013 9:18 AM
>     *To:* John Bradley
>     *Cc:* Mike Jones; Vladimir Dzhuvinov / NimbusDS;
>     openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     *Subject:* Re: [Openid-specs-ab] proposed POST response type for
>     OAuth/Connect
>
>     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)
>
>     On Oct 18, 2013 9:15 AM, "Breno de Medeiros" <breno at google.com
>     <mailto:breno at google.com>> wrote:
>
>     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.
>
>     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.
>
>     On Oct 18, 2013 8:50 AM, "John Bradley" <ve7jtb at ve7jtb.com
>     <mailto:ve7jtb at ve7jtb.com>> wrote:
>
>     I am OK with response_mode or response_encoding.
>
>     John B.
>
>     On 2013-10-18, at 12:46 PM, Mike Jones
>     <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
>     wrote:
>
>     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?
>
>     If I don’t hear objections or alternative suggestions, I’ll change
>     to using that.
>
>     -- Mike
>
>     *From:* Breno de Medeiros [mailto:breno@ <mailto:breno@>google.com
>     <http://google.com>]
>     *Sent:* Friday, October 18, 2013 5:48 AM
>     *To:* Vladimir Dzhuvinov / NimbusDS
>     *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     *Subject:* Re: [Openid-specs-ab] proposed POST response type for
>     OAuth/Connect
>
>     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.
>
>     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.
>
>     On Oct 18, 2013 5:42 AM, "Breno de Medeiros" <breno at google.com
>     <mailto:breno at google.com>> wrote:
>
>     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.
>
>     On Oct 18, 2013 1:49 AM, "Vladimir Dzhuvinov / NimbusDS"
>     <vladimir at nimbusds.com <mailto:vladimir at nimbusds.com>> wrote:
>
>     Hi Mike, hi guys,
>
>     I read the proposed spec and it looks good to me. Making the
>     "what" and
>     the "how" orthogonal parameters is great.
>
>     Vladimir
>
>     --
>     Vladimir Dzhuvinov : www.NimbusDS.com <http://www.NimbusDS.com> :
>     vladimir at nimbusds.com <mailto:vladimir at nimbusds.com>
>
>
>
>
>     -------- Original Message --------
>     Subject: Re: [Openid-specs-ab] proposed POST response type for
>     OAuth/Connect
>     From: Mike Jones <Michael.Jones at microsoft.com
>     <mailto:Michael.Jones at microsoft.com>>
>     Date: Fri, October 18, 2013 8:02 am
>     To: "<openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>>"
>     <openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>>
>
>     As Breno suggested, I’ve made the proposed changes to the Multiple
>     Response Types spec. These changes do two things:
>     1. Disentangle the specification of what parameters are to be
>     returned (which is done with the response_type parameter) from the
>     specification of how they are to be returned (which is done with the
>     response_encoding parameter).
>     2. Define a POST response encoding that can be used to request
>     that parameters be returned via form POST.
>
>     The response_encoding parameter is only used when a non-default
>     encoding is requested, so these changes will no effect on current
>     implementations.
>
>     I’ve posted an updated version at
>     http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html.
>     The .xml source is posted there as well. Also, diffs from the current
>     BitBucket version can be viewed as tracked changes in the Word version
>     at
>     http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx.
>
>     Tomorrow I’ll review the current Connect specs and make the following
>     related proposed changes:
>     ? Add the response_encodings_supported discovery parameter.
>     ? Review the places where fragment encoding is explicitly or
>     implicitly specified, making sure the language doesn’t prohibit using
>     the POST response encoding instead. (Note that we should do this now,
>     even should we don’t adopt POST as part of the core now, so we don’t
>     preclude it in the future.)
>     (I’d make these changes now, but it’s probably better that I do it
>     when I’m not tired.)
>
>     Anyway, this wasn’t hard and the result isn’t difficult to
>     understand or implement. (And implementation will remain optional.)
>
>     Thanks to Breno, John, and Brian for the feedback on how this should
>     work. Thanks especially to Brian for posting his draft, which I
>     borrowed some text and the example from.
>
>     -- Mike
>
>     From: Breno de Medeiros [mailto:breno at google.com
>     <mailto:breno at google.com>]
>     Sent: Thursday, October 17, 2013 4:02 PM
>     To: Mike Jones
>     Cc: Brian Campbell; <openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>>
>     Subject: Re: [Openid-specs-ab] proposed POST response type for
>     OAuth/Connect
>
>
>
>     On Thu, Oct 17, 2013 at 11:37 AM, Mike Jones
>     <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
>     wrote:
>     Thanks, Brian. This is really useful. I suspect I’ll be using
>     some of your text in my write-up. J
>
>     I just spent some time on the phone with Breno discussing this and he
>     agreed that defining a POST response at this point is reasonable. When
>     talking about possible ways of specifying the POST response
>     behavior, he
>     stated the principle that when a behavioral change is being requested,
>     that this should be done so dynamically, rather than via registration.
>     That way, particular clients can be updated to use this behavior
>     without
>     requiring a new client registration. (He likes using registration to
>     specify behavioral restrictions, however, such as requiring particular
>     signing/encryption algorithms, etc.)
>
>     He said that the way that he’d do it is to include a
>     “transport=POST” parameter in the authorization request. So
>     that’s what I’ll write up. We could later than define
>     “transport=postMessage”, “transport=CORS”, etc. if we decide to
>     do so.
>
>
>
>
>     I think this is sufficiently small that we might be able to
>     undertake in
>     a short time-frame. I believe that POST support will prove useful. I'd
>     recommend this to be added to the new response types part of the spec:
>     http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html,
>     for a number of reasons: It already has the burden to deal with the
>     security properties of different encoding formats for different
>     response
>     types, and would be a small change in scope to change it to talk about
>     'transport' modes instead of encoding. That spec also has been stable
>     and changed little for a long time, so the chance that it can be
>     re-written w/o side-effects is probably higher.
>
>
>
>
>
>
>
>
>     As an aside, Breno also said that the reason that he thinks Session
>     Management isn’t yet ready to be final, is that he’d like us to
>     explore the option of using a CORS transport, rather than postMessage
>     within Session Management. I’ll leave it to Breno to say more about
>     this.
>
>     Thanks
>     all,
>     -- Mike
>
>     From: openid-specs-ab-bounces at lists.openid.net
>     <mailto:openid-specs-ab-bounces at lists.openid.net>
>     [mailto:openid-specs-ab-bounces at lists.openid.net
>     <mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Brian
>     Campbell
>     Sent: Thursday, October 17, 2013 8:56 AM
>     To: <openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>>
>     Subject: [Openid-specs-ab] proposed POST response type for
>     OAuth/Connect
>
>     As discussed during today's call [1], attached is the
>     pseudo-standard document I wrote up earlier this year describing
>     an HTTP
>     POST response type (effectively a POST binding) for OAuth/OIDC.
>
>     I know everyone has a lot of docs to read right now but this one is
>     *very* short and has a good example.
>
>     We've found this approach to work well in practice and be easy to
>     implement.
>
>     It can be done as a straight extension, as illustrated with this
>     doc, or
>     could incorporated into core connect.
>
>
>
>     As John mentioned, the main drawback of this approach is proliferation
>     of the Response Types registry. Which is kind of ugly but
>     something that
>     no one will care much about once it's done. It's also more of a
>     consequence of the response type constructs put forth by OAuth than it
>     is with this particular extension.
>
>     Thanks,
>     Brian
>
>
>     [1]
>     http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     --
>     --Breno
>
>
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>     _______________________________________________
>
>     Openid-specs-ab mailing list
>
>     Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> -- 
> Nat Sakimura (n-sakimura at nri.co.jp <mailto:n-sakimura at nri.co.jp>)
> 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.
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- 
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/bb28173f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/bb28173f/attachment-0001.png>


More information about the Openid-specs-ab mailing list