[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.html>
More information about the Openid-specs-ab
mailing list