Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
Brian Campbell <bcampbell@pingidentity.com> Fri, 31 March 2017 13:38 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C833C1297DE for <oauth@ietfa.amsl.com>; Fri, 31 Mar 2017 06:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03-kCpeutXY9 for <oauth@ietfa.amsl.com>; Fri, 31 Mar 2017 06:38:37 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1C11297BF for <oauth@ietf.org>; Fri, 31 Mar 2017 06:38:27 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id 81so71654992pgh.2 for <oauth@ietf.org>; Fri, 31 Mar 2017 06:38:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gxcZDLNhYyZPRKwd4i0ztI4IP2pbOrudIDocSwgY8lA=; b=VtMoM0I4ex9ny4Sbp68KS0wLDMZikFKB2QgFovSJurd0cW2M6v7A9wSW0T59jlvTdj 2RMKl/CEjW0v278pAxYY9CxE+iJF/fVcUk7vCAkx3qM+rSMx+7VWUDtokvi1XQthDgqk kVM6SKy16yufUe/+7vfSLzju30i2oohsmFi+o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gxcZDLNhYyZPRKwd4i0ztI4IP2pbOrudIDocSwgY8lA=; b=p6zMonyvW9xJzV8dFxrPa4D/Bf4iBl512Vl36Pyhh1voJd+ijVQy4HBFOTCTqg//88 wu6OPdIs2gSlAdBmF90x45RQwOJ+vzwDB3Z6XTDfcqXQz8GmCmIrLa+7Th1KMAVzUrrK fvHI35L4t1coe1H1kX6m7qmrtxDpiwMZ7/CgaynuZE3BrBS6vCe6Ck9J8g720DZKIOvs xkR8fII4JhrleKbIElffBsUzM2YF/azOPU/DifSuHmejY3VY30OugI9FfrUDWFP0bNdd 2xpz36kCT3C3Qo+xrzmkdRjWhRUF/eksa1uasKrCJSPbQhw4BrE79pOgmuDQvm6+JqNB RuYQ==
X-Gm-Message-State: AFeK/H2jI4XJ+3FKzE5rPZO8+FVc0sBMAX2nhwqr16ck7FvTcn/5MmG7p1IT4UuVpzvQwlc5o45RHMxuaYEFo1B0
X-Received: by 10.98.220.200 with SMTP id c69mr3004080pfl.60.1490967506626; Fri, 31 Mar 2017 06:38:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.165.172 with HTTP; Fri, 31 Mar 2017 06:37:56 -0700 (PDT)
In-Reply-To: <CA+k3eCTKHRB_dKeUEurZX5vDzCw+HhEgUZiHUnyd61oNjmogRw@mail.gmail.com>
References: <CAANoGhJDKgqWaqhdL6TCO7RhE==h=ZmJeKbU-cuwUZwE+siHMA@mail.gmail.com> <n6swy6f6jws7vdnx4rs66ktg.1490929049898@email.android.com> <58ddcfc3.5c2e6b0a.7b9e3.bbc6@mx.google.com> <B4C58688-6933-4E46-BA80-15E5E8B38F6F@lodderstedt.net> <58ddd7a5.e4886b0a.bf30d.bce7@mx.google.com> <CA+k3eCTKHRB_dKeUEurZX5vDzCw+HhEgUZiHUnyd61oNjmogRw@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 31 Mar 2017 08:37:56 -0500
Message-ID: <CA+k3eCR8Amr8+b+Sh9eR=VDzJme+bcB8WhkokcPpgmgaEMZMGQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, IETF oauth WG <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>
Content-Type: multipart/alternative; boundary="f403045cc42e9aced1054c06ec05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RCjUmJ7njN-LrRWMK43JWMaeSlg>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2017 13:38:41 -0000
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 >> >> >
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Brian Campbell
- [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13… internet-drafts
- [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsre… John Bradley
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… Mike Jones
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… John Bradley
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… Mike Jones
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… Nat Sakimura
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… John Bradley
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… sakimura@gmail.com
- Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-j… John Bradley
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… John Bradley
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Sergey Beryozkin
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Brian Campbell
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsre… Nat Sakimura