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

John Bradley ve7jtb at ve7jtb.com
Fri Oct 18 15:49:53 UTC 2013


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/7cdd2ff0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/7cdd2ff0/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list