Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Filip Skokan <panva.ip@gmail.com> Fri, 31 January 2020 14:46 UTC
Return-Path: <panva.ip@gmail.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 B769E120804; Fri, 31 Jan 2020 06:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3pLKBdelYLwt; Fri, 31 Jan 2020 06:46:48 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 873A312007C; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id f129so8972410wmf.2; Fri, 31 Jan 2020 06:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=SiyCNKtEE350zJsS+BB1rEKU+aMjWjtueKdmo7VlbuBau6Vu86r7fvpO22AEAhA0RM ju1hZPL2EU6VGHLEcCFgUpVMPsSvvj6FU4XbpCUqLXyvkI3zEQhp+c8Md7IkbGQzNJ8O qmWJp1bS3RpGtMs+llajgdaW2DV3683R/gLhg/SBHJFki/EvovQtbLMaIduY3y+Wq7PQ I2xFpbr2aZ5pINKXdKhUKF8KFaGNazEsrK7T1DWSdNvm6Zhyc/dV5VqhIbrGmaiXH/cu 05vxZXHVXYdiePBKdpHrolpu/oNqWGd+YKHmV3alvxFRNMhkIjyj6WLuc0feBgy34SjP dL3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=WYr16KlwCMsD9sDusPFNVZU1DILvnJ+/rKwkR4Ud5O0=; b=cjZRhMuQnJfroZ2UyVx92Fkb400lB/TEq/7MdgeVPQ4Yyuz9uM9He3WXed48nLdcrZ s02jxvZfGA6C0SJpwu/ia/QfGhesF3fY6ixpk0tbh2r5HSo2K0M0WW+I1X6edczPZ3sV zk4BEdjjQqhf+4cv4Ex99/JApykUa9sHIiz8PzIPjtIM0AfSUSiDFBMgJIMdhqpkrxlv i0G4lZ1HE81t5FjWQ5PzDkIBqPxbrTj6xfdez9qiqpSLouiutZ6hsA2J+sXlyskMlVxH cZZPBRsJMVjT0KjY0YrVmM3m/h/NMygyQ5SEPSTdPI7S3ZZ3e6ByYdimbNbMxR8d9RHv 2Iag==
X-Gm-Message-State: APjAAAU0OoxDTBpTa3JfdVO0g+qRF0EadAKuio3WPsAZm5iGCNXbCyZr qr4NlfVBHD0otUpxzLSSjw==
X-Google-Smtp-Source: APXvYqyGf15WyfNmCrugFRFXn5awUao7hl4g7lLNUDzzKF26BM0rIH/jDma/2tAA74LUGSIqpHGcPw==
X-Received: by 2002:a05:600c:2207:: with SMTP id z7mr12724086wml.138.1580482005713; Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Received: from [192.0.2.1] ([8.40.30.20]) by smtp.gmail.com with ESMTPSA id e8sm11937489wrt.7.2020.01.31.06.46.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 06:46:45 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Filip Skokan <panva.ip@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jan 2020 15:46:44 +0100
Message-Id: <8D83F40F-3E17-427D-9606-3453BA00DDFC@gmail.com>
References: <CH2PR00MB06786F235896AB63594D11FAF5070@CH2PR00MB0678.namprd00.prod.outlook.com>
In-Reply-To: <CH2PR00MB06786F235896AB63594D11FAF5070@CH2PR00MB0678.namprd00.prod.outlook.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, "draft-ietf-oauth-jwsreq@ietf.org" <draft-ietf-oauth-jwsreq@ietf.org>, oauth <oauth@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>
X-Mailer: iPhone Mail (17C54)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AVlO397Xp6Me8kHTc3glvl7XGYk>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: 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:46:52 -0000
I also agree and support that client_id outside of the request object be usable for the purposes described earlier, given that it is also a MUST it be present in the request object with the same value as outside. Odesláno z iPhonu > 31. 1. 2020 v 15:31, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>: > > I also agree that we must allow client_id to be expressed outside of the signed request, as described by Nat. > > -- Mike > > -----Original Message----- > From: OAuth <oauth-bounces@ietf.org> On Behalf Of John Bradley > Sent: Friday, January 31, 2020 6:25 AM > To: Nat Sakimura <sakimura@gmail.com>; Benjamin Kaduk <kaduk@mit.edu> > Cc: oauth <oauth@ietf.org>; oauth-chairs@ietf.org; The IESG <iesg@ietf.org>; draft-ietf-oauth-jwsreq@ietf.org > Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT) > >> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >>> .ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01 >>> %7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7 >>> C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sd >>> ata=6ZSWckU9w8S1oDEUz%2BgKPguV2UFjyfzKrOIt9V4qXRQ%3D&reserved=0 >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd >>>>> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-jwsreq%2F&data=02% >>>>> 7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a659 >>>>> 6612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63716077521867674 >>>>> 0&sdata=eaeSN%2BgKTCDiy502GPNm459JjYuOj5o77Tp%2B6QAw3HY%3D& >>>>> reserved=0 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> --- >>>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=L2bwEdfW4tbnTI5FSJTCC%2BkI3EA6CqNNqZ5FzT0JnRs%3D&reserved=0", >>>>> "response_type": "code id_token", >>>>> "client_id": "s6BhdRkqt3", >>>>> "redirect_uri": "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclient.example.org%2Fcb&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=XBvLTF0JuNuz7I3c7pBel0GNSN0lcYqvoHCNagAwrSU%3D&reserved=0", >>>>> "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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> server.example.com&data=02%7C01%7CMichael.Jones%40microsoft.com >>>>> %7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011d >>>>> b47%7C1%7C0%7C637160775218676740&sdata=L2bwEdfW4tbnTI5FSJTCC%2B >>>>> kI3EA6CqNNqZ5FzT0JnRs%3D&reserved=0", >>>>> "response_type": "code id_token", >>>>> "client_id": "s6BhdRkqt3", >>>>> "redirect_uri": >>>>> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>> client.example.org%2Fcb&data=02%7C01%7CMichael.Jones%40microsof >>>>> t.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7c >>>>> d011db47%7C1%7C0%7C637160775218676740&sdata=XBvLTF0JuNuz7I3c7pB >>>>> el0GNSN0lcYqvoHCNagAwrSU%3D&reserved=0", >>>>> "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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcapability-urls%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=QtofXDXbUc2U2ieJYh0wFHXGivLFuU64GhsxCW9pD9M%3D&reserved=0 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 mailing list > OAuth@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C659127cedd5a42ecbfed08d7a6596612%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637160775218676740&sdata=55Hdt6W1uELCC%2BhFrFvOcPDN%2F5zpcSNQmJFogxAoi9g%3D&reserved=0 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [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