Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
John Bradley <ve7jtb@ve7jtb.com> Fri, 31 January 2020 14:25 UTC
Return-Path: <ve7jtb@ve7jtb.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 ED3A712011E for <oauth@ietfa.amsl.com>; Fri, 31 Jan 2020 06:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 xB51j88B5Ix6 for <oauth@ietfa.amsl.com>; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 56F71120104 for <oauth@ietf.org>; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
Received: by mail-qt1-x843.google.com with SMTP id t13so5523791qto.3 for <oauth@ietf.org>; Fri, 31 Jan 2020 06:25:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jssWvkuWkZNoY2zsWTbml1xH4PEQ9oNd3Wubw72ckcY=; b=V/RvuR+nITPe749T2xDjvyl8Im2VZ8XQijaeZu0YkszgeleVit7bHa3CR2qEJglIfz c3c2F1NmNmA4oyCfifKIJMzG70WXQ3+xkfKwq91ML1QfPG8dSOA4sDfH7D9vxXiIgNgs TsiFVGmU8IjtClhlE5TUeA+GkW9grkOcF6JbcGKA8wSHGqfPwV6ixmnoO50AMnRis8db Gubo6ytYbhZRT7Gt+/B9gTiWd2A6ggZGAergmFVFEaOHCvYF5742tQ61aI4ZVUpU47Yy GYmWmcvbcDAWqdtrxbzHd1YLPSWmoshsjs2ycGpTguZJE1Apb8WDfRxzEnUDBqlzbesu eaGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=jssWvkuWkZNoY2zsWTbml1xH4PEQ9oNd3Wubw72ckcY=; b=ng2Z+iCDNZUJaQF2eQ4iKgcctISIwgiWQy+hZw3J4OjSqb6mBY+ydMOjx8tLI4L/R5 hcoIcXK1FNCyjAc49MF3Pp0j2c9+CZW8QMxn4Qqn6uqdFm8Ee+54lc/7HjOnI3DiEIRe Cak9zG/nDEW0rXbd4G3vEFq+Ph1LrduOZ5CFwrvSf/gkrw5M+o6ynDJESEWsYwp2emUo gqbaHSCTHsiYyz250Q4ItaTwUkU0IWh4CUmQK4jA+gx/MoFUziRqFtjQ0VYpI2SzCTJK wFfdyblyIOURoi0iJpSO/Ws1e/KEBq6YBMy+8Cn9OlkJ5qb2JgUmkQsBIqqCCLUpD5pj IrXA==
X-Gm-Message-State: APjAAAXXw2dO7QUQeL/QWyOxk0eZUUsnue2XcP8KVPrPAFmmf41oLijU AQZQdeZaYYpKBvHK7Xw+Uzk5jLfQs8K7Ew==
X-Google-Smtp-Source: APXvYqx1aVbvcCvITR5TJ1jLTZukzVCKlUeoswykfMtPi0F3Dc95WCIGLS8UNOPkGZiU7AJpcLDGqw==
X-Received: by 2002:ac8:1e08:: with SMTP id n8mr10724730qtl.175.1580480706708; Fri, 31 Jan 2020 06:25:06 -0800 (PST)
Received: from [192.168.8.103] ([190.107.226.39]) by smtp.gmail.com with ESMTPSA id n20sm4449590qkk.54.2020.01.31.06.25.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:25:05 -0800 (PST)
To: Nat Sakimura <sakimura@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-jwsreq@ietf.org, oauth <oauth@ietf.org>, oauth-chairs@ietf.org
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com> <CABzCy2BWV6+gyaSNkjJjWHMk-xx0iB2A2aDxEssf9EuaEjXR8w@mail.gmail.com> <20200129232014.GN48797@kduck.mit.edu> <CABzCy2CVSdb7ALw7-6tP3Pnw5jwOxAGx1UM81BjeyhugZ8BsvA@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <012da3b1-083a-7ee4-3f27-bdc78ef2c9a0@ve7jtb.com>
Date: Fri, 31 Jan 2020 11:25:01 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <CABzCy2CVSdb7ALw7-6tP3Pnw5jwOxAGx1UM81BjeyhugZ8BsvA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wRTROuCtc9gk9HA7a9m69lYgOIQ>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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 Jan 2020 14:25:12 -0000
>From the discussions I have had, I agree with Nat's assment. John B. On 1/31/2020 12:06 AM, Nat Sakimura wrote: > Hi > > Re: JWT > I understand your concern and we can put some explanatory notes. Having > said that, JAR is still a valid JWT, I think :-) > > Re: client_id > We actually discussed client_id issues with OpenID Connect WG Call > yesterday as well. > I hear a pretty strong voice from the developer community that they want > client_id as a query parameter and it should not pose a security issue as > long as it is required to match what is in the JWT. In fact, that was the > position taken in the WG last call. So, in effect, WG is actually pushing > back the change IESG wanted. > > As I understand it, there are two points to be made: > (1) If client_id is not in the query parameter, then it MUST be in the JWT > header OR MUST be supplied as a query parameter in some encrypted JAR case > (2) To check if requst_uri is a registered and valid URI, not having > client_id in the query parameter will have performance impacts in a large > AS. > > The encryption case (1) can be solved by adding client_id in the JWT Header > but it will not solve (2). > So, IMHO, putting client_id back to the query parameter (and MUST match the > value in JWT) is a way to go. > Since that was the position by the WG at the WG Last Call, I do not feel > that it needs to be brought back to the WG last call, > but that is your call. > > Best, > > Nat Sakimura > > On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk <kaduk@mit.edu> wrote: > >> Hi Nat, >> >> Now it is my turn to apologize for taking a long time. >> >> I think I see the general direction these changes are going in, and it's a >> reasonable approach to the unfortunate situation we find ourselves in with >> respect to JWT claims vs. OAuth parameters. In effect, what we're doing is >> making a "profile" (for lack of a better term) of JWT, that leverages the >> mechanisms and algorithms of JWT but uses a different registry for >> interpreting the claims in the token (that is, OAuth Parameters vs. JWT >> Claims). We can tell that this "profile" of JWT is being used because of >> the context in which the JWT is transferred/received: if it's the "request" >> parameter, that's part of the definition of the OAuth Parameter, and if >> it's the result of dereferencing a "request_uri", the >> application/oauth.authz.req+jwt media-type clearly indicates how the >> contents should be interpreted. >> >> However, the changes in the -20 do not give the reader much of any hint as >> to this being what's expected to happen, and that stock RFC 7519 JWT is >> *not* what's in use. So I'd request that we take a close look at how the >> document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement >> that while the JWT encoding is in use, the contents are to be interpreted >> by interpreting the JWT claims as OAuth Parameters (and not as per the IANA >> registry of JWT claims); and add some discussion (similar to the above) >> about how the application context makes it unambiguous whether the >> JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this >> document. >> >> With respect to my second ("discuss discuss") point, Nat and I did have a >> discussion in-person and I accept that there may be some scenarios in which >> skipping the authorization dialogue is appropriate, so the example can >> remain. >> >> >> Moving on from my Discuss position, I do get the sense from the ongoing >> discussion on the list that there's not clear agreement about the current >> formulation that requires all parameters (but "request" and "request_uri") >> to be in the JAR, especially with respect to "client_id" that might be >> needed to unpack the JAR in some cases! So I'm not sure whether the WG >> wants to bring the document back to the WG to iron out those issues before >> it returns to the IESG. I'm a little reluctant to switch my position to >> "No Objection" until we have a clearer picture of what the WG wants to do >> on this front -- in my understanding, we can't really publish the document >> without at least some solution ("client_id") for the encrypted-request >> key-lookup case. >> >> Thanks, >> >> Ben >> >> >> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote: >>> Hi >>> >>> Took a long time but finally all the changes needed to resolve the >> DISCUSS >>> comments are (hopefully) applied as -20. >>> >>> There is one change that impacts the process: the draft now has IANA >>> request so it needs to be referred back to IANA. >>> >>> The IETF datatracker status page for this draft is: >>> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >>> >>> Best, >>> >>> Nat Sakimura >>> >>> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker <noreply@ietf.org>: >>> >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-oauth-jwsreq-19: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> This is a "discuss discuss" -- it's an important question and I'd like >>>> to talk about it, but it's not clear that any change to the document >>>> will be needed. >>>> >>>> Once this (and some of the more substantive items in the Comment >>>> section) is resolved, I'd be happy to ballot Yes. >>>> >>>> The introduction notes as an advantage of JWT that: >>>> >>>> (d) (collection minimization) The request can be signed by a third >>>> party attesting that the authorization request is compliant >> with >>>> a certain policy. For example, a request can be pre-examined >> by >>>> a third party that all the personal data requested is strictly >>>> necessary to perform the process that the end-user asked for, >>>> and statically signed by that third party. The authorization >>>> server then examines the signature and shows the conformance >>>> status to the end-user, who would have some assurance as to the >>>> legitimacy of the request when authorizing it. In some cases, >>>> it may even be desirable to skip the authorization dialogue >>>> under such circumstances. >>>> >>>> I'm pretty uncomfortable about suggesting that the authorization >>>> dialogue can/should be skipped; do we need to keep this example? >>>> Maybe just talking about what an expected use case could be would >>>> help alleviate my unease. >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Section 1 >>>> >>>> While it is easy to implement, the encoding in the URI does not >> allow >>>> application layer security with confidentiality and integrity >>>> protection to be used. While TLS is used to offer communication >>>> >>>> nit: this wording is a little hard to read; it might be easier to >>>> reorder to "does not allow application layer security to be used to >>>> provide confidentiality and integrity protection". >>>> >>>> The use of application layer security allows requests to be prepared >>>> by a third party so that a client application cannot request more >>>> permissions than previously agreed. This offers an additional >> degree >>>> of privacy protection. >>>> >>>> (side note) what would an example of such a third party be. (We >> already >>>> have the resource owner, the client, and the authorization server ... >>>> maybe it's a fourth party?) >>>> >>>> Furthermore, the request by reference allows the reduction of over- >>>> the-wire overhead. >>>> >>>> We only barely mentioned by-reference at this point (one line in the >>>> Abstract), so I'd suggest "passing the request by reference". >>>> >>>> (4) its development status that it is an RFC and so is its >>>> associated signing and encryption methods as [RFC7515] and >>>> [RFC7516] >>>> >>>> nit: I'd suggest "its development status as a Proposed Standard, along >>>> with the associated signing and encryption methods [RFC7515] >> [RFC7516]." >>>> (c) (confidentiality protection) The request can be encrypted so >>>> that end-to-end confidentiality can be provided even if the TLS >>>> connection is terminated at one point or another. >>>> >>>> nit: TLS is always terminated at or before the user-agent, though. So >>>> maybe the user agent needs to get called out here as well (there could >>>> of course be TLS termination earlier than the user-agent in some cases, >>>> too). >>>> >>>> 2. When the client does not want to do the crypto. The >>>> Authorization Server may provide an endpoint to accept the >>>> Authorization Request through direct communication with the >>>> Client so that the Client is authenticated and the channel is >> TLS >>>> protected. >>>> >>>> How can you "not want to do [the] crypto" but still be doing TLS (with >>>> crypto)? Perhaps we're looking for "not want to pay the additional >>>> overhead of JWS/JWE cryptography on top of TLS"? >>>> >>>> Section 1.1 >>>> >>>> RFC 8174 has updated BCP 14 boilerplate text to use. >>>> >>>> Section 3 >>>> >>>> nit: should this section be 2.3 to get wrapped into "terminology"? >>>> >>>> It might also be worth putting references in for the terms, though they >>>> are largely common knowledge at this point. >>>> >>>> Section 4 >>>> >>>> A Request Object (Section 2.1) is used to provide authorization >>>> request parameters for an OAuth 2.0 authorization request. It MUST >>>> contains all the OAuth 2.0 [RFC6749] authorization request >> parameters >>>> including extension parameters. The parameters are represented as >>>> >>>> nit: "all the parameters" kind of sounds like "all that are defined". >>>> But I think the intent here is "any parameter used to process the >>>> request must come from the request object and URL query parameters are >>>> ignored", so maybe "MUST contain all the parameters (including >> extension >>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization >>>> request; parameters from other sources MUST NOT be used", akin to what >>>> we say down in Sections 5 and 6.3. >>>> But we need to be careful about the wording to not exclude the usage of >>>> the "request" and "request_uri" query parameters to find the Request >>>> Object! >>>> >>>> the JWT claims. Parameter names and string values MUST be included >>>> >>>> nit: maybe "the JWT claims of the object"? >>>> >>>> any extension parameters. This JSON [RFC7159] constitutes the JWT >>>> Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then >>>> signed or signed and encrypted. >>>> >>>> nit: I think we want "This JSON [RFC7159] object". >>>> >>>> (Long quote incoming) >>>> >>>> The following is an example of the Claims in a Request Object before >>>> base64url encoding and signing. Note that it includes extension >>>> variables such as "nonce" and "max_age". >>>> >>>> { >>>> "iss": "s6BhdRkqt3", >>>> "aud": "https://server.example.com", >>>> "response_type": "code id_token", >>>> "client_id": "s6BhdRkqt3", >>>> "redirect_uri": "https://client.example.org/cb", >>>> "scope": "openid", >>>> "state": "af0ifjsldkj", >>>> "nonce": "n-0S6_WzA2Mj", >>>> "max_age": 86400 >>>> } >>>> >>>> Signing it with the "RS256" algorithm results in this Request Object >>>> value (with line wraps within values for display purposes only): >>>> >>>> eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 >>>> F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl >>>> c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk >>>> JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w >>>> bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW >>>> Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog >>>> ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ >>>> ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p >>>> Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS >>>> wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg >>>> ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH >>>> sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu >>>> dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm >>>> luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs >>>> F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF >>>> KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx >>>> 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K >>>> ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG >>>> iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw >>>> >>>> Decoding the base64 of the body, we see: >>>> { >>>> "iss": "s6BhdRkqt3", >>>> "aud": "https://server.example.com", >>>> "response_type": "code id_token", >>>> "client_id": "s6BhdRkqt3", >>>> "redirect_uri": "https://client.example.org/cb", >>>> "scope": "openid", >>>> "state": "af0ifjsldkj", >>>> "nonce": "n-0S6_WzA2Mj", >>>> "max_age": 86400, >>>> "claims": >>>> { >>>> "userinfo": >>>> { >>>> "given_name": {"essential": true}, >>>> "nickname": null, >>>> "email": {"essential": true}, >>>> "email_verified": {"essential": true}, >>>> "picture": null >>>> }, >>>> "id_token": >>>> { >>>> "gender": null, >>>> "birthdate": {"essential": true}, >>>> "acr": {"values": ["urn:mace:incommon:iap:silver"]} >>>> } >>>> } >>>> } >>>> >>>> I'm not sure where the "claims" claim is coming from -- 6749 doesn't >>>> seem to talk about it. (Note that this example is used later on as >>>> well.) >>>> >>>> Section 5.2.1 >>>> >>>> It is possible for the Request Object to include values that are to >>>> be revealed only to the Authorization Server. As such, the >>>> "request_uri" MUST have appropriate entropy for its lifetime. For >>>> the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED >>>> that it be removed after a reasonable timeout unless access control >>>> measures are taken. >>>> >>>> It sounds like a link to https://www.w3.org/TR/capability-urls/ might >>>> also be useful. >>>> >>>> Section 5.2.2 >>>> >>>> Do we want to remind the reader that the other query parameters are >> just >>>> for backwards compatibility? >>>> >>>> Section 5.2.3 >>>> >>>> The following is an example of this fetch process: >>>> >>>> GET /request.jwt HTTP/1.1 >>>> Host: tfp.example.org >>>> >>>> It's useful to show good hygeine in examples; can we get the extra >>>> entropy in this request that we have in the previous example(s)? >>>> >>>> Section 6.2 >>>> >>>> The Authorization Server MUST perform the signature validation of >> the >>>> JSON Web Signature [RFC7515] signed request object. For this, the >>>> "alg" Header Parameter in its JOSE Header MUST match the value of >> the >>>> pre-registered algorithm. The signature MUST be validated against >>>> the appropriate key for that "client_id" and algorithm. >>>> >>>> Does "the pre-registered algorithm" concept exist in the specs outside >>>> of draft-ietf-oauth-jwt-bcp? >>>> >>>> Section 9 >>>> >>>> The error codes we list in Section 7 are already registered, for the >>>> OIDC usage. Do we want to say anything about that? (I guess it would >>>> be disallowed by process to try to update the existing registration to >>>> also point at this document.) >>>> >>>> Section 10 >>>> >>>> We probably also want to reference draft-ietf-oauth-jwt-bcp. >>>> >>>> Section 10.1 >>>> >>>> When sending the authorization request object through "request" >>>> parameter, it MUST either be signed using JWS [RFC7515] or encrypted >>>> using JWE [RFC7516] with then considered appropriate algorithm. >>>> >>>> Up in Section 5 we only allow (a) signed and (b) signed then encrypted; >>>> similarly, in Section 4 we reiterate "signed then encrypted". Why is >> it >>>> okay to talk about just "signed or encrypted" here? >>>> >>>> Section 10.2 >>>> >>>> (b) Verifying that the symmetric key for the JWE encryption is the >>>> correct one if the JWE is using symmetric encryption. >>>> >>>> Similarly to the previous point, you also need to check the signature, >>>> which will always be there. >>>> >>>> (d) Authorization Server is providing an endpoint that provides a >>>> Request Object URI in exchange for a Request Object. In this >>>> >>>> I don't think this is a complete sentence (and it's definitely not a >>>> parallel construction with (a)-(c)!). I think perhaps a crisp one-line >>>> summary of this method would be "Delegating the authorization check to >> a >>>> separate "Request Object to Request Object URI" endpoint on the >>>> Authorization Server". (The writing in the rest of this paragraph >> could >>>> also use an editing pass.) >>>> >>>> (e) A third party, such as a Trust Framework Provider, provides an >>>> endpoint that provides a Request Object URI in exchange for a >>>> Request Object. The same requirements as (b) above apply. In >>>> addition, the Authorization Server MUST know out-of-band that >>>> the Client utilizes the Trust Framework Operator. >>>> >>>> The Authorization Server also has to trust the third-party provider to >>>> actually do its job and not misbehave, right? >>>> >>>> Section 10.3 >>>> >>>> I'm not entirely sure what "[t]he endpoints ithat come into question in >>>> this specification" is supposed to mean -- is it just "the OAuth 2.0 >>>> endpoints presently defined in Standards-Track RFCs"? >>>> >>>> In [RFC6749], while Redirection URI is included, others are not >>>> included in the Authorization Request. As the result, the same >>>> applies to Authorization Request Object. >>>> >>>> nit: included in what? >>>> >>>> Section 10.4 >>>> >>>> It's probably also worth citing the generic URI security considerations >>>> from RFC 3986, here. >>>> >>>> Section 10.4.1 >>>> >>>> "request_uri", and (d) do not perform recursive GET on the >>>> "request_uri". >>>> >>>> nit: remove the "do" in order to make the construction parallel. >>>> >>>> Section 12.1 >>>> >>>> It is often hard for the user to find out if the personal data asked >>>> for is strictly necessary. A Trust Framework Provider can help the >>>> user by examining the Client request and comparing to the proposed >>>> processing by the Client and certifying the request. After the >>>> certification, the Client, when making an Authorization Request, can >>>> submit Authorization Request to the Trust Framework Provider to >>>> obtain the Request Object URI. >>>> >>>> side note: In my head the act of certification was the act of making >> the >>>> translation to a Request Object URI, so I'm kind of curious where my >>>> vision differs from reality. >>>> >>>> The third paragraph seems to mostly just be describing the procedure of >>>> how this flow works, which would not necessarily be specific to the >>>> privacy considerations section. >>>> >>>> Section 12.2.2 >>>> >>>> Even if the protected resource does not include a personally >>>> identifiable information, it is sometimes possible to identify the >>>> user through the Request Object URI if persistent per-user Request >>>> Object URI is used. A third party may observe it through browser >>>> >>>> nit: need an article for "persistent per-user Request Object URI" (or >>>> make it plural, as "URIs are used"). >>>> >>>> Therefore, per-user Request Object URI should be avoided. >>>> >>>> nit: I think this is better as "static per-user Requeste Object URIs"
- [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Nat Sakimura
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Benjamin Kaduk
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Nat Sakimura
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… John Bradley
- Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Di… Mike Jones
- Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Di… Filip Skokan