Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

and a typo - "If thie location is" should say "If this location is"

On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> BTW, the intro still has text about 'dynamic parameters such as "state"'
> that need to be cleaned up.  https://tools.ietf.org/html/
> draft-ietf-oauth-jwsreq-13#section-1
>
> On Fri, Mar 31, 2017 at 8:36 AM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
>
>> "The current text causes the AS to ignore them and not return a error. "
>> - except that I don't believe the current text actually specifies that
>> anywhere. And I think that the intent of Mike's original comment was that
>> -13 doesn't specify the behavior but that it needs to be revised to do so.
>>
>> I'd suggest that the doc say that the client must include in the request
>> object (request or request_uri) all the oauth parameters that it sends. And
>> when request or request_uri is sent, that the AS must/should only rely on
>> parameter values from the request object.
>>
>> I think being semi or somewhat compatible or tolerant of the Connect
>> variation or request/request_uri is good because it uses the same parameter
>> names, the same endpoint, and the same metadata names.
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 30, 2017 at 11:14 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>>> They are mutually exclusive.
>>>
>>>
>>>
>>> However there are two options as to how the authorization endpoint would
>>> treat extra query parameters like state if they are sent.
>>>
>>>
>>>
>>> The current text causes the AS to ignore them and not return a error.
>>> This would be more backwards compatible with the request object in OpenID
>>> Connect, however in reality it may cause connect clients to send parameters
>>> as query parameters  that would be processed by a connect server that would
>>> be ignored by a OAuth server without any obvious error.  There may however
>>> be subtle errors downstream from missing parameters.
>>>
>>>
>>>
>>> The other option is to have a cleaner breaking change from Connect and
>>> have the Authorization endpoint return a error if anything other than the
>>> two new parameters are sent to the authorization endpoint.
>>>
>>>
>>>
>>> I am leaning towards the latter as it is easier to debug,  and wont
>>> allow incompatible Connect requests to be accepted without a error.   We
>>> would have done this in Connect but couldn’t drop required parameters from
>>> OAuth in a Connect spec.
>>>
>>>
>>>
>>> The downside for the latter is that the client would need to know if the
>>> AS is supporting The Connect version or the OAuth version.
>>>
>>>
>>>
>>> One of the typical conundrums around how to deal with doing the best
>>> going forward thing vs not blowing up older implementations.
>>>
>>>
>>>
>>> In the current proposal a client could put the required parameters both
>>> places and the same request would work on servers supporting both the
>>> Connect and OAuth versions.
>>>
>>>
>>>
>>> John B.
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *Torsten Lodderstedt <torsten@lodderstedt.net>
>>> *Sent: *March 30, 2017 11:01 PM
>>> *To: *John Bradley <ve7jtb@ve7jtb.com>
>>> *Cc: *Nat Sakimura <sakimura@gmail.com>; Nat Sakimura <nat@sakimura.org>;
>>> IETF oauth WG <oauth@ietf.org>
>>> *Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>>
>>>
>>>
>>> I had assumed using the request object is mutual exclusive to use of URI
>>> query parameters. Did I misinterpret the draft?
>>>
>>>
>>>
>>> Am 30.03.2017 um 22:40 schrieb John Bradley <ve7jtb@ve7jtb.com>:
>>>
>>>
>>>
>>> It is a trade off between compatibility with Connect and possible
>>> configuration errors.
>>>
>>>
>>>
>>> In reality it may not be compatible with Connect if the client is
>>> sending some parameters outside the object without including them in the
>>> object as a Connect client might.    You would potentially wind up dropping
>>> state or nonce without an error.
>>>
>>>
>>>
>>> I asked Mike and he was leaning to making it a error to send them as
>>> query parameters as that would be a clean change.
>>>
>>>
>>>
>>> I think the choice is a bit of a grey area.
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *sakimura@gmail.com
>>> *Sent: *March 30, 2017 9:57 PM
>>> *To: *John Bradley <ve7jtb@ve7jtb.com>; Nat Sakimura <nat@sakimura.org>
>>> *Cc: *IETF oauth WG <oauth@ietf.org>
>>> *Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>>
>>>
>>>
>>> +1
>>>
>>> Sent from my Huawei Mobile
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>> From: John Bradley
>>> To: Nat Sakimura
>>> CC: IETF oauth WG
>>>
>>> So I think we need to make the must ignore clearer for the additional
>>> paramaters on the authorization endpoint.
>>>
>>>
>>>
>>> On Mar 30, 2017 17:33, "Nat Sakimura" <nat@sakimura.org> wrote:
>>>
>>> Not right now.
>>>
>>> As of this writing, a client can still send duplicate parameters in the
>>> query but they get ignored by the servers honoring OAuth JAR. So, it is
>>> backwards compatible with OpenID Connect in that sense (OpenID Connect
>>> sends duplicate manatory RFC6749 parameters as the query parameters as well
>>> just to be compliant to RFC6749). Conversely, servers that do not support
>>> OAuth JAR will ignore request_uri etc.
>>>
>>> On Mar 30, 2017, at 4:47 PM, Mike Jones <Michael.Jones@microsoft.com>
>>> wrote:
>>>
>>> Is there a clear statement somewhere along the lines of “parameters
>>> (other than “request” or “request_uri”) are only allowed to be in the
>>> signed object if a signed object is used”?  That’s the kind of thing I
>>> was looking for and didn’t find.
>>>
>>>
>>>
>>>                                                        -- Mike
>>>
>>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com]
>>> *Sent:* Thursday, March 30, 2017 4:44 PM
>>> *To:* Mike Jones <Michael.Jones@microsoft.com>
>>> *Cc:* Nat Sakimura <nat@sakimura.org>; IETF oauth WG <oauth@ietf.org>
>>> *Subject:* RE: [OAUTH-WG] FW: I-D Action:
>>> draft-ietf-oauth-jwsreq-13.txt
>>>
>>>
>>>
>>> The intent of the change is to only allow the paramaters to be in the
>>> signed object if a signed object is used.
>>>
>>>
>>>
>>> This requires State, nonce etc to be in the JWT.  Only one place to
>>> check will hopefully reduce implimentation errors.
>>>
>>>
>>>
>>> This also allows us to remove the caching text as we now have one JWT
>>> per request, so caching won't happen.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mar 30, 2017 4:36 PM, "Mike Jones" <Michael.Jones@microsoft.com>
>>> wrote:
>>>
>>> I **believe** the intent is that **all** parameters must be in the
>>> request object, but the spec doesn’t actually say that, as far as I can
>>> tell.  Or maybe the intent is that parameters must not be duplicated
>>> between the query parameters and the request object.
>>>
>>>
>>>
>>> One or the other of these statements should be explicitly included in
>>> the specification.  Of course, I could have missed the statement I’m asking
>>> for in my review, in which case please let me know what I missed.
>>>
>>>
>>>
>>>                                                        Thanks,
>>>
>>>                                                       -- Mike
>>>
>>>
>>>
>>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John
>>> Bradley
>>> *Sent:* Thursday, March 30, 2017 3:00 PM
>>> *To:* IETF OAUTH <oauth@ietf.org>
>>> *Subject:* [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>>
>>>
>>>
>>> Based on feeback from the IESG we have removed some of the optionality
>>> in the draft.
>>>
>>>
>>>
>>> It is a shorter read than draft 12.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *internet-drafts@ietf.org
>>> *Sent: *March 30, 2017 1:38 PM
>>> *To: *i-d-announce@ietf.org
>>> *Cc: *oauth@ietf.org
>>> *Subject: *[OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
>>>
>>>
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>>
>>>
>>>
>>>         Title           : The OAuth 2.0 Authorization Framework: JWT
>>> Secured Authorization Request (JAR)
>>>
>>>         Authors         : Nat Sakimura
>>>
>>>                           John Bradley
>>>
>>>            Filename        : draft-ietf-oauth-jwsreq-13.txt
>>>
>>>            Pages           : 27
>>>
>>>            Date            : 2017-03-30
>>>
>>>
>>>
>>> Abstract:
>>>
>>>    The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>>>
>>>    query parameter serialization, which means that Authorization Request
>>>
>>>    parameters are encoded in the URI of the request and sent through
>>>
>>>   user agents such as web browsers.  While it is easy to implement, it
>>>
>>>    means that (a) the communication through the user agents are not
>>>
>>>    integrity protected and thus the parameters can be tainted, and (b)
>>>
>>>    the source of the communication is not authenticated.  Because of
>>>
>>>    these weaknesses, several attacks to the protocol have now been put
>>>
>>>    forward.
>>>
>>>
>>>
>>>    This document introduces the ability to send request parameters in a
>>>
>>>    JSON Web Token (JWT) instead, which allows the request to be signed
>>>
>>>    with JSON Web Signature (JWS) and/or encrypted with JSON Web
>>>
>>>    Encryption (JWE) so that the integrity, source authentication and
>>>
>>>    confidentiality property of the Authorization Request is attained.
>>>
>>>    The request can be sent by value or by reference.
>>>
>>>
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>
>>>
>>>
>>> There are also htmlized versions available at:
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-13
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-13
>>>
>>>
>>>
>>> A diff from the previous version is available at:
>>>
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-13
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>>
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>>
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>