Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is Ready. The main JWS spec (RFC 7515) required that the signed payload was base64url-encoded prior to signing. This results in a noticeable size expansion; in some circumstances it is desirable to avoid this expansion and reencoding. I did not follow the JWS document closely at the time, but I believe this issue was raised at the time and consensus reached on the published version because it is always safe for applications to use. This document provides an opt-in mechanism for application (protocol)s to avoid the extra encoding and expansion, leaving the burden on the application to determine whether it is safe to do so and perform the relevant input checking/sanitization. The security considerations correctly describe the implications of the loss of encoding and the restrictions on the signed content when detached payloads are not used, interoperability concerns for applications not supporting the b64 header parameter, and proposes appropriate countermeasures. Interestingly, this document does not need to update the JWS spec, since it is just adding to an IANA registry and not modifying the core spec, but it does update the JWT spec (RFC 7519) to prohibit the use of b64=false in JWTs. No justification is made for this restriction in the text of the document, but it seems reasonable to "play it safe" in this sense, to me. I do have a few nits unrelated to the security review: The abstract mentions the "Updates: 7519", but the introduction does not; I am sometimes told that both locations should mention the update, but I assume that the RFC Editor will notice if anything needs to change. It is a bit amusing that the example with payload "$.02" is actually longer with the unencoded payload, due to the overhead of the header field, but I do not suggest modifying the example at this time. Section 5.3 makes reference to Section 8.3 of RFC 7159 for JSON string-escape processing, but I think perhaps section 7 of that RFC would be a better reference. Relatedly, I needed to reread the text in Section 5.3 a few times in order to convince myself that I correctly understood the procedure for generating the payload to be signed, but I believe that all the steps given are necessary and correct, and do not have proposed text that would be better. String-escape processing is just inherently fiddly. I did not attempt to verify the examples' encoding and consistency. Thanks for this well-written document. -Ben