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

Mike Jones Michael.Jones at microsoft.com
Fri Oct 18 16:44:02 UTC 2013


You mean application/x-www-form-urlencoded?  Yes, I can add that.

From: Breno de Medeiros [mailto:breno at google.com]
Sent: Friday, October 18, 2013 9:29 AM
To: Mike Jones
Cc: openid-specs-ab at lists.openid.net; Vladimir Dzhuvinov / NimbusDS; John Bradley
Subject: RE: [Openid-specs-ab] proposed POST response type for OAuth/Connect


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<mailto: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<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131018/a7dc49b4/attachment-0001.html>


More information about the Openid-specs-ab mailing list