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

Torsten Lodderstedt torsten at lodderstedt.net
Sat Oct 19 17:31:08 UTC 2013


+1



John Bradley <ve7jtb at ve7jtb.com> schrieb:
>I recall that the requirement for TLS if used for authentication was a
>later addition to the OAuth spec.
>
>It probably is sufficient, however it may not be a bad Idea to always
>make it TLS for form_post to avoid confusion by developers.
>
>John B.
>On 2013-10-19, at 5:21 AM, Torsten Lodderstedt
><torsten at lodderstedt.net> wrote:
>
>> Hi George,
>>> 
>>> Another thought, do we have to explicitly require that if the
>html_form response_mode is used, then the redirect_url MUST have a
>scheme of https? If the initial request is from a 'confidential' client
>then OAuth2 and OpenID Connect allow the redirect_url to be http.
>> 
>> How did you come to this conclusion? OAuth requires clients using the
>authorization response data for authentication purposes to use HTTPS.
>> 
>> http://tools.ietf.org/html/rfc6749#section-10.5
>> 
>> "Authorization codes operate as plaintext bearer credentials, used to
>verify that the resource owner who granted authorization at the
>authorization server is the same resource owner returning to the client
>to complete the process.  Therefore, if the client relies on the
>authorization code for its own resource owner authentication, the
>client redirection endpoint MUST require the use of TLS."
>> 
>> regards,
>> Torsten.
>> 
>>> 
>>> Given the above, I have some concerns that by trying to rush the
>additions into the specs we are going to miss something important.
>>> 
>>> Thanks,
>>> George
>>> 
>>> On 10/18/13 2:00 PM, Mike Jones wrote:
>>>> Or possibly “form_POST”?  What do others think?
>>>>  
>>>> I’ve updated Discovery to add proposed text for the
>“response_modes_supported” parameter.  See:
>>>>               
>http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html
>>>>               
>http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx
>>>>  
>>>> I also updated the Multiple Response Types drafts posted to specify
>the encoding for the POST response, as Breno suggested.
>>>>  
>>>> I’ll finish the updates to Core to update the normative text that
>currently requires fragment encoding Implicit and Hybrid response
>parameters when I get back from an appointment in a few hours.
>>>>  
>>>>                                                             -- Mike
>>>>  
>>>> From: n-sakimura [mailto:n-sakimura at nri.co.jp] 
>>>> Sent: Friday, October 18, 2013 10:49 AM
>>>> To: Mike Jones
>>>> Cc: Breno de Medeiros; John Bradley;
>openid-specs-ab at lists.openid.net
>>>> Subject: Re: [Openid-specs-ab] proposed POST response type for
>OAuth/Connect
>>>>  
>>>> POST is a misleading name for the response mode / response
>encoding. 
>>>> 
>>>> Even with fragment, one could potentially use POST. In fact, that
>would be one of the easiest implementation choice for the fragment
>encoding case: it is just a few lines of Javascript code, such as:
>>>> 
>>>> 
>>>>     RelayToken: function (url,callback) {
>>>>         // calllback proto = function(data){ .... } 
>>>>         token = $.FVAR("token");
>>>>         state = $.FVAR("state")
>>>>         if (token) {
>>>>             $.post(url, { token: token, state: state
>}).done(callback);
>>>>         }
>>>>     }
>>>>  
>>>> 
>>>> What you are describing as POST in fact is the representation of
>the authorization grant in HTML Form. So, instead of POST, 'html_form'
>or simply 'html' is a more             approriate description. 
>>>> 
>>>> (2013/10/19 1:22), Mike Jones 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] 
>>>> Sent: Friday, October 18, 2013 9:18 AM
>>>> To: John Bradley
>>>> Cc: Mike Jones; Vladimir Dzhuvinov / NimbusDS;
>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>
>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
>>>>  
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Nat Sakimura (n-sakimura at nri.co.jp)
>>>> Nomura Research Institute, Ltd. 
>>>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>>>  
>>>>
>本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
>>>>  6;|
>>>> 14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
>>>> PLEASE READ:
>>>> The information contained in this e-mail is confidential and
>intended for the named recipient(s) only.
>>>> If you are not an intended recipient of this e-mail, you are hereby
>notified that any review, dissemination, distribution or duplication of
>this message is strictly prohibited. If you have received this message
>in error, please notify the sender immediately and delete your copy
>from your system.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> -- 
>>> <XeC>
>>> _______________________________________________
>>> 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/20131019/3c54a221/attachment-0001.html>


More information about the Openid-specs-ab mailing list