)Be ye not afraid -- I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operation area directors. Document editors and WG chairs should treat these comments just like any other last call comments. For OpsAD: Ready with nits / after IETF LC. Version reviewed: draft-ietf-oauth-jwsreq-09 Summary: Purely from OpsDir side it looks OK. From an editorial side though there are lots of nits / places where I found the text to be less than clear. AFAICT, this has not yet gone through IETF LC (last I saw was from Kathleen putting it on the telechat and saying a IETF LC would happen after a new version is posted - https://mailarchive.ietf.org/arch/msg/oauth/Eg6dqFD72A6jlR6A34ZMQMWIYw0 This version was last updated September 28, 2016) - just mentioning because a: more comments might come in LC, and to make sure it isn't accidentally missed.) I'm not quite sure why there is a sales pitch for 29100 ( "ISO/IEC 29100 [ISO29100] is a freely accessible International Standard and its Privacy Principles are good to follow.") - I'd suggest dropping at least the "freely accessible" part, or adding it to all of the IETF references as well :-P Nits: Abstract This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS [O] JWS [R] -- I don't think that JWS / JWE are in the well-known acronym list. I think, especially for an abstract that these should be made clear. signed and/or JWE encrypted so that the integrity, source authentication and confidentiallity property of the Authorization [O] confidentiallity [P] confidentiality [R] spelling 1. Introduction The Authorization Request in OAuth 2.0 [RFC6749] utilizes query parameter serialization and typically sent through user agents such [O] and typically sent [P] and is typically sent [R] missing a verb. While TLS is used to offer communication security between the Client and the user-agent and the user-agent and the Authorization Server, TLS sessions are terminated in the user- [O] the Client and the user-agent and the user-agent and the Authorization Server, [P] the Client and the user-agent as well as the user-agent and the Authorization Server, [R] readability; the initial version with "and" almost makes it sound as though all four things are connected, vs two sets of two. agent. In addition, TLS sessions may be terminated prematurely at some middlebox (such as a load balancer). As the result, the Authorization Request of [RFC6749] has a property that [O] has a property that [P] has the following limitations [or concerns] [R] the list that follows aren't really "properties," and it sounds a little awkward -- but I'm not sure what exactly to replace it with. Because of these weaknesses, several attacks against the protocol, such as Redirection URI rewriting, has been discovered. [O] several attacks [...] has been discovered. [R] at a minimum, we need to change "has" to "have" -- but beyond that, are attacks discovered? Or is the issue that attacks are open? Maybe, "Because of these weaknesses, the protocol is vulnerable to various attacks, including Redirection URI rewriting." The use of application layer security mitigates these issues. In addition, it allows requests to be prepared by a third party so [O] In addition, it allows [P] The use of application layer security also allows [R] readability that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. Furthermore, the request by reference allows the reduction of over- the- wire overhead. [O] the- wire [P] the-wire [R] punctuation/grammar The JWT [RFC7519] encoding has been chosen because of (1) its close relationship with JSON, which is used as OAuth's response format; (2) its developer friendliness due to its textual nature; The parameters "request" and "request_uri" are introduced as additional authorization request parameters for the OAuth 2.0 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters. This JWT is integrity protected and source authenticated using JWS. The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter "request_uri" is used instead 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 client would then send the request along with dynamic parameters such as state. 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. [O] ; [P] [R] the semicolons are not necessary -- the list is already separated by lines and letters. There are a few cases that request by reference are useful such as: 4. 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. [O] : The [P] . The [R] #1 & 2 have no colon after the initial sentence; 3 & 4. It is not necessary, and I suggest that it's removed for consistency. This capability is in use by OpenID Connect [OpenID.Core]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Request Object This JSON [RFC7159] constitutes the JWT Claims Set [RFC7519]. The JWS Claims Set is then signed, encrypted, or signed and encrypted. [O] then signed, encrypted, or signed and encrypted. [P] then signed, or encrypted, or signed and encrypted. [R] I am *guessing* this is what's meant" Otherwise, it's not clear whether "signed, encrypted" is supposed to be an OR or an and. Upon further reading of the document, I think this is supposed to mean, "signed, or encrypted, or signed and encrypted." If the parameter exists in both the query string and the Authorization Request Object, the values in the Request Object take precedence. This means that if it intends to use a cached request object, it cannot include parameters such as "state" that are expected to differ in every request. It is fine to include them in [O] It is fine [P] It is recommended (or acceptable, or expected..."fine" doesn't mean much in this context.) [R] clarity the request object if it is going to be prepared afresh every time. 5.2.1. URL Referencing the Request Object The Client stores the Request Object resource either locally or remotely at a URL the Authorization Server can access. The URL MUST be HTTPS URL. This URL is the Request Object URI, "request_uri". It is possible for the Request Object to include values that is to be [O] values that is [P] values that are [R] grammar revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. It is RECOMMENDED that it be removed if it is known that it will not be used again or after a reasonable timeout unless access control measures are taken. 6.2. JWS Signed Request Object To perform JWS Signature Validation, the "alg" Header Parameter in the JOSE Header MUST match the value of the pre-registered algorithm. [O] JOSE [R] No idea who JOSE is, or where he came from; this is the only reference to JOSE in this document. I'd suggest reference to the WG or one of the JOSE RFCs. 7. Authorization Server Response Authorization Server Response is created and sent to the client as in Section 4 of OAuth 2.0 [RFC6749] . In addition, this document uses these additional error values: invalid_request_uri The "request_uri" in the Authorization Request returns an error or contains invalid data. invalid_request_object The request parameter contains an invalid Request Object. request_not_supported The Authorization Server does not support the use of the "request" parameter. request_uri_not_supported The Authorization Server does not support use of the "request_uri" parameter. 8. TLS Requirements Client implementations supporting the Request Object URI method MUST support TLS as recommended in Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC7525]. Sakimura & Bradley Expires April 1, 2017 [Page 14] Internet-Draft OAuth JAR September 2016 To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection. Whenever TLS is used, the identity of the service provider encoded in the TLS server certificate MUST be verified using the procedures described in Section 6 of [RFC6125]. 9. IANA Considerations This specification requests no actions by IANA. 10. Security Considerations In addition to the all the security considerations discussed in OAuth 2.0 [RFC6819], the following security considerations should be taken into account. 10.1. Choice of Algorithms When sending the authorization request object through "request" parameter, it MUST either be JWS signed with then considered appropriate algorithm or encrypted using [RFC7516]. 10.2. Choice of Parameters to include in the Request Object Unless there is a compelling reasons to do otherwise, it is strongly recommended to create a request object that covers all the parameters so that the entire request is integrity protected. This means that the request object is going to be prepared fresh each time an authorization request is made and caching cannot be used. It 10.4. Explicit Endpoints Although this specification does not require them, researchs such as [O] researchs [P] research [R] spelling 11. Privacy Considerations When the Client is being granted access to a protected resource containing personal data, both the Client and the Authorization Server need to adhere to Privacy Principles. ISO/IEC 29100 [ISO29100] is a freely accessible International Standard and its Privacy Principles are good to follow. Most of the provision would apply to The OAuth 2.0 Authorization Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer Token Usage [RFC6750] and not specific to this specification. In [O] and not specific [P] and are not specific [R] grammar what follows, only the specific provisions to this specification are noted. 11.1. Collection limitation When the Client is being granted access to a protected resource containing personal data, the Client SHOULD limit the collection of personal data to that which is within the bounds of applicable law and strictly necessary for the specified purpose(s). 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 11.2.2. Tracking using Request Object URI It is in a way a data disclosure as well and should be avoided. [O] It is in a way a data disclosure as well and should be avoided. [P] In a way, it is a data disclosure as well, and thus should be avoided. [R] readability Therefore, per-user Request Object URI should be avoided. 12. Acknowledgements The following people contributed to the creation of this document in the OAuth WG. (Affiliations at the time of the contribution is [O] contribution is [P] contribution are [R] grammar/subject verb agreement used.) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf