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