Hi Nat, Hi John,

thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the document ready for the IESG and have therefore reviewed it.

Despite some minor issues I believe the document is in good shape.

Here are my comments:

** Introduction

The example request in the introduction is longer than 72 characters.

s/textaual nature/textual nature

s/The request may be encrypted so that end-to-end confidentiality may be obtained even if in the case TLS connection is terminated at a gateway or a similar device. /The request may be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at a gateway.

FROM:

The request can be signed so that an integrity check can be implemented. If a suitable algorithm is used for the signing, then it will provide verification of the client making the request.

TO: 1. The request may be signed so that the signer can be authenticated and the integrity of the request can be checked.

There are a few cases that request by reference are useful such as:

FROM:

When it is desirable to reduced the size of transmitted request. Since we are using application layer security, it may substantially increase the size of the request particulary in the case of using public key cryptography.

TO:

When it is desirable to reduce the size of transmitted request. The use of application layer security increases the size of the request, particularly when public key cryptography is used.

You write:

Static signature: The client can make a signed Request Object and put it at a place that the Authorization Server can access. This may just be done by a client utility or other process, so that the private key does not have to reside on the client, simplifying programming. Downside of it is that the signed portion just become a token.

The downside is that there is that there is no indication of freshness and I believe this is what you mean by "just became a token". I am not sure that the term 'static signature' is the right term here. Just delete the 'Static Signature:'.

Is the JWT a good match to encode the parameters of the request? Why don't you just use a regular JSON object and apply the JOSE security mechanisms to it.

Section 3: Request Object

You write:

" To encrypt, JWE [RFC7516] is used. Note that JWE is always integrity protected, so if only integrity protection is desired, JWS signature is not needed. "

I think the last sentence should say: "... if only integrity protection is desired then JWE is not needed."

You write:

" It can also be signed then encrypted. This is sometimes desired to reduced the repudiation risk from the point of view of the receiver. In this case, it MUST be signed then encrypted, with the result being a Nested JWT, as defined in JWT [RFC7519]. "client_secret

What do you mean by "reduced the repudiation risk"?

It may help if you reference the example in Appendix A.2 of RFC 7519 regarding a nest JWT.

You write:

REQUIRED OAuth 2.0 Authorization Request parameters that are not included in the Request Object MUST be sent as query parameters. If a required parameter is missing from both the query parameters and the Request Object, the request is malformed.

s/REQUIRED/Required

That's a bit unfortunate that you have to send parameters twice -- once as query parameters and then again in the request object. Is there no better way to design this?

Section 4: Authorization Request

You write:

The authorization request object MAY be signed AND/OR encrypted.

Why is this sentence needed when you have extensively spoken about this topic already in earlier chapters? If you include it then write "The authorization request object MAY be signed and/or encrypted."

For the entire document I believe it is worthwhile to state in the terminology section that your usage of the term "signed" means digitally signing with asymmetric crypto system as well as using a MAC (which is a symmetric key primitive).

You write:

" Servers MAY cache the contents of the resources referenced by Request URIs. If the contents of the referenced resource could ever change, the URI SHOULD include the base64url encoded SHA-256 hash as defined in FIPS180-2 [FIPS180-2] of the referenced resource contents as the fragment component of the URI. If the fragment value used for a URI changes, that signals the server that any cached value for that URI with the old fragment value is no longer valid. "

I am not sure what this means. Can you provide an example?

You list a couple of restrictions of the request URI below"

" The entire Request URI MUST NOT exceed 512 ASCII characters. There are three reasons for this restriction.

Many WAP / feature phones do not accept large payloads. The restriction are typically either 512 or 1024 ASCII characters.
The maximum URL length supported by older versions of Internet Explorer is 2083 ASCII characters.
On a slow connection such as 2G mobile connection, a large URL would cause the slow response and using such is not advisable from the user experience point of view. "

I wonder how relevant they are (given that the size of the URI is substantially increased due to the use of JWT & the JOSE work). For example, are there still many WAP phones around that want to use this mechanism? Are old versions of the Internet Explorer still an issue?

Is a request by value even an option for a 2g mobile phone?

Section 5. Validating JWT-Based Requests

You write: "The Authorization Server MUST return an error if decryption fails." and "The Authorization Server MUST return an error if signature validation fails." Could you be a bit more precise about the error message that is returned? From Section 6 I don't see what the right error response would be.

Section 8. Security Considerations:

FROM:

In addition to the all the security considerations discussed in OAuth

2.0 [RFC6819], the following security considerations SHOULD be taken into account.

TO:

In addition to the all the security considerations discussed in OAuth

2.0 [RFC6819], the following security considerations should be taken into account.

You write:

" When sending the authorization request object through "request" parameter, it SHOULD be signed with then considered appropriate algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such a case. "

The use cases presented in the document talk about end-to-end security and signed / encrypted requests. Now, in the security consideration section it almost appears if there is the possibility that the request object would not experience any security protection at all.

That does not appear right. It does not make sense to just send the parameters in a different encoding only, or does it? I would only see a disadvantage doing that, namely the much larger size.

You write:

" If the request object contains personally identifiable or sensitive information, the "request_uri" MUST be of one-time use and MUST have large enough entropy deemed necessary with applicable security policy. For higher security requirement, using [RFC7516] is client_secretstrongly recommended. "

Why is this so? Today, we send the same request in OAuth over TLS. Why is there only a problem with the request_uri and not with sending the request object?

I believe the biggest issue that should be discussed in the security consideration section is the possibility that the request object may not be fresh. This introduces the possibility for replay attacks and lowers the quality of the end-to-end security protection.

It may also be good to motivate the application layer security mechanisms a bit more. For example, what information is in the request itself that requires encryption?

When I looked at the example I noticed the client_id and the absence of the client_secret. I wonder how the mechanism intersects with the client_id and the client_secret. If a client has, for example, a public / private key pair configured then the use of JWS (with those credentials) would provide much better security than a client_id and a client_secret.

** Section 11: References

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, http://www.rfc-editor.org/info/rfc5246.

Could you reference the TLS BCP instead? https://tools.ietf.org/html/rfc7525

[FIPS180-2] U.S. Department of Commerce and National Institute of Standards and Technology, "Secure Hash Signature Standard", FIPS 180-2, August 2002.

          Defines Secure Hash Algorithm 256 (SHA256)

Could you reference RFC 6234 instead? https://tools.ietf.org/html/rfc6234

Ciao Hannes

Hannes Comments

** Introduction

Section 3: Request Object

You write:

You write:

You write:

Section 4: Authorization Request

You write:

Comments (3)