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

Breno de Medeiros breno at google.com
Fri Oct 18 12:42:54 UTC 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/1313bb4f/attachment-0001.html>


More information about the Openid-specs-ab mailing list