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

[Sergey Beryozkin <[e-mail]>]

Hi John

I see a line in our implementation checking that if a response_type is 
also available as a query parameter then it must match the request claim 
value.
Would it make sense to require checking all the well-known query 
parameters and if they exist - enforcing they must also be available in 
the request object ?

Sergey
On 31/03/17 05:14, John Bradley 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 <mailto:[e-mail]>
> *Sent: *March 30, 2017 11:01 PM
> *To: *John Bradley <mailto:[e-mail]>
> *Cc: *Nat Sakimura <mailto:[e-mail]>; Nat Sakimura
> <mailto:[e-mail]>; IETF oauth WG <mailto:[e-mail]>
> *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 <[e-mail]
>     <mailto:[e-mail]>>:
>
>
>
>     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: *[e-mail] <mailto:[e-mail]>
>     *Sent: *March 30, 2017 9:57 PM
>     *To: *John Bradley <mailto:[e-mail]>; Nat Sakimura
>     <mailto:[e-mail]>
>     *Cc: *IETF oauth WG <mailto:[e-mail]>
>     *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" <[e-mail]
>         <mailto:[e-mail]>> 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
>             <[e-mail]
>             <mailto:[e-mail]>> 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:[e-mail]
>                 <mailto:[e-mail]>]
>                 *Sent:* Thursday, March 30, 2017 4:44 PM
>                 *To:* Mike Jones <[e-mail]
>                 <mailto:[e-mail]>>
>                 *Cc:* Nat Sakimura <[e-mail]
>                 <mailto:[e-mail]>>; IETF oauth WG
>                 <[e-mail] <mailto:[e-mail]>>
>                 *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"
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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:[e-mail]
>                     <mailto:[e-mail]>] *On Behalf Of *John
>                     Bradley
>                     *Sent:* Thursday, March 30, 2017 3:00 PM
>                     *To:* IETF OAUTH <[e-mail]
>                     <mailto:[e-mail]>>
>                     *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: *[e-mail]
>                     <mailto:[e-mail]>
>                     *Sent: *March 30, 2017 1:38 PM
>                     *To: *[e-mail]
>                     <mailto:[e-mail]>
>                     *Cc: *[e-mail] <mailto:[e-mail]>
>                     *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 <http://tools.ietf.org/>.
>
>
>
>                     Internet-Drafts are also available by anonymous FTP at:
>
>                     ftp://ftp.ietf.org/internet-drafts/
>
>
>
>                     _______________________________________________
>
>                     OAuth mailing list
>
>                     [e-mail] <mailto:[e-mail]>
>
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>