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

Breno de Medeiros breno at google.com
Fri Oct 18 16:29:08 UTC 2013


Which reminds me that we should specify encoding of POST method.
On Oct 18, 2013 9:22 AM, "Mike Jones" <Michael.Jones at microsoft.com> 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
> *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> 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> 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>
> 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 at google.com]
> *Sent:* Friday, October 18, 2013 5:48 AM
> *To:* Vladimir Dzhuvinov / NimbusDS
> *Cc:* Mike Jones; 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> 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> 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 : 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>
> Date: Fri, October 18, 2013 8:02 am
> To: "<openid-specs-ab at lists.openid.net>"
> <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]
>  Sent: Thursday, October 17, 2013 4:02 PM
>  To: Mike Jones
>  Cc: Brian Campbell; <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> 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] On Behalf Of Brian
> Campbell
>  Sent: Thursday, October 17, 2013 8:56 AM
>  To: <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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/c695e5a5/attachment-0001.html>


More information about the Openid-specs-ab mailing list