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
