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:tors...@lodderstedt.net>
*Sent: *March 30, 2017 11:01 PM
*To: *John Bradley <mailto:ve7...@ve7jtb.com>
*Cc: *Nat Sakimura <mailto:sakim...@gmail.com>; Nat Sakimura
<mailto:n...@sakimura.org>; IETF oauth WG <mailto: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 <ve7...@ve7jtb.com
<mailto:ve7...@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: *sakim...@gmail.com <mailto:sakim...@gmail.com>
*Sent: *March 30, 2017 9:57 PM
*To: *John Bradley <mailto:ve7...@ve7jtb.com>; Nat Sakimura
<mailto:n...@sakimura.org>
*Cc: *IETF oauth WG <mailto: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" <n...@sakimura.org
<mailto:n...@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.jo...@microsoft.com
<mailto:michael.jo...@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:ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>]
*Sent:* Thursday, March 30, 2017 4:44 PM
*To:* Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
*Cc:* Nat Sakimura <n...@sakimura.org
<mailto:n...@sakimura.org>>; IETF oauth WG
<oauth@ietf.org <mailto: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.jo...@microsoft.com
<mailto:michael.jo...@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-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *John
Bradley
*Sent:* Thursday, March 30, 2017 3:00 PM
*To:* IETF OAUTH <oauth@ietf.org
<mailto: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-dra...@ietf.org
<mailto:internet-dra...@ietf.org>
*Sent: *March 30, 2017 1:38 PM
*To: *i-d-annou...@ietf.org
<mailto:i-d-annou...@ietf.org>
*Cc: *oauth@ietf.org <mailto: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 <http://tools.ietf.org/>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
