Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Nat Sakimura <sakimura@gmail.com> Sun, 27 October 2019 09:13 UTC
Return-Path: <sakimura@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 CEB3112006F; Sun, 27 Oct 2019 02:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=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 aCFlIDsvcDrO; Sun, 27 Oct 2019 02:13:08 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 C99F9120104; Sun, 27 Oct 2019 02:13:04 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id g24so6365651wmh.5; Sun, 27 Oct 2019 02:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/oRU6sT0Wg/77pLF3VQRPl9E0Z4rZiL/hiFXeaw2cdA=; b=sOFPOmbzbv3v7/TZkZK4nYDQkEFnxnhU4dYjeA5l80K5pxkOXhk5/zwG0T2YbP0OAX 87Ta7C9UlqTeYAEbl/5xufJJcmb6NOiI/wpFs1TkMdyu5q+1Y0sfBPc72foY5F77VDgx dQJ3HfEr7msHDLvJV0hksYV2a1o1sgfMM4PXAEu+tDlwEToALTOK09bR2Ou+mGYURpQV HdD9OkU3oWgXxcWwKyvS+HjzV1JxCisA86HFvSDT3Ds5MFddGIgIyXEE5KwSwf33lkyR M6FR4JFMtKF1XiTXYFWWGNqo3WvKcel0lnEDK5b7DEWFsGhWfZ5cy9BPk9Uk+MU8JbFh 2Crw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/oRU6sT0Wg/77pLF3VQRPl9E0Z4rZiL/hiFXeaw2cdA=; b=YTrlpqVo/EtTUh05FHNstKbpGW6A0go8pAcY0YAP2KxxUURh3V2EEH9lGnuUGTybmP dysHnuraMuX2mBV5/MUSYjt1wj4yDTo8sKfJrHk4Nmxy2TyvH5ki6eib2aBD+CPZboKz EAAK+brQ7RXK/bKNHPzJaXU7dzZLbqYnPOb5wott7JWb9OXtboe/Dq4MNyxSr/CJhHuR tNeX8srx4kTT3QrRXhoq8w9tbg6RPqxsItZukqJNhzHoQ7cghC1CGq1dgTZMskBNveoK J4m2XyDbdglYeboYQzfwugULxZC6GGHx+o57hs2+CUxkxIKudGxOm5b1D9HznJ9x5oU+ uJXA==
X-Gm-Message-State: APjAAAUQSg0gVHF8HQd3ONO74eLhwSktPYDYGf3KyNrB0GV8FIR69abq EtR/LXB8mITmzk/sNw8cAjtXOfslBIRixoJpbOOXLwy/YeU=
X-Google-Smtp-Source: APXvYqwqzUR5EXfcVbmr67lEVBR/tMNoSj39uwb5FYwtNG6Yt5cFgv2FBJmXy+58wNzTeLrOaIc1UfEh8jFI38eGyhQ=
X-Received: by 2002:a05:600c:2255:: with SMTP id a21mr4130335wmm.148.1572167582565; Sun, 27 Oct 2019 02:13:02 -0700 (PDT)
MIME-Version: 1.0
References: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com>
In-Reply-To: <156209885136.23990.13347837808208602644.idtracker@ietfa.amsl.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Sun, 27 Oct 2019 10:12:50 +0100
Message-ID: <CABzCy2BWV6+gyaSNkjJjWHMk-xx0iB2A2aDxEssf9EuaEjXR8w@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000494aea0595e0ca6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7GxJt0KXgfLm0Na1YCsMbDANRy0>
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: Sun, 27 Oct 2019 09:13:13 -0000
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". > > Section 13 > > Are there two different paragraphs for "contributions from the OAuth WG > members"? Are they reflecting different types of contribution? > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
- [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