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

Fri Oct 18 16:17:51 UTC 2013

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/2e6210fb/attachment.html>