(1) This is to be a Standards Track ocument. This is correctly reflected on the document.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
JSON Web Signature (JWS) [RFC 7515] represents the payload as a base64url encoded value and uses this value in the Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines an alternate signature computation method that avoids the
requirement to base64url-encode the payload.
Working Group Summary
This document defines an alternate method to form the octet string that signatures are computed over for a JWS object. This was the main focus of the discussions as it means that there are now potentially two different messages, one with and one without base64 encoding, that will have the same signature value. The group believes that this has been adequately addressed in the current document.
The document comes with examples of the new signatures, these examples have been validated by a non-author implementation. A number of people have indicated that they are either planning to implement or are considering implementing the change in the signature scheme here. Note that the document explicitly states that the JOSN Web Token community is not going to take this change.
Jim Schaad acted as the Document Shepherd and Kathleen Moriarty is the Responsible Area Director.
(3) The document was read in it's entirety for the last two versions to check for completeness and correctness. This included going over the nits and looking at the mailing list to check that all consensus of the list was reflected in the document. It was verified that the examples had been checked for correctness by at least one other person than the author.
(4) The document has been throughly reviewed by the working group and by the document shepherd. Additionally, since there is an update of an OAuth documnent, a request for OAuth review was requested as well. No comments on the draft from the OAuth WG were noted.
(5) It would be nice to get additional confirmation of the examples, however they have been checked. I believe that the security questions of the document have been sufficiently reviewed.
(6) The fact that there are two different versions of encoding that produce the same text string for signing is worrisome to me. The WG had the ability to address this when producing the JWS specification and decided not to do so that time. In this document, the desire to allow for things to be smaller has lead to the fact that the b64 and crit headers can be omitted as being implicit. This was the desire of the WG, but I personally feel that it is the wrong decision.
(7) Mike Jones has confirmed that he knows of no IPR for this document.
(8) No IPR disclourses exist for this document.
(9) This is a solid WG consensus. The individuals who might have objected to this document have long since left the WG.
(10) Nobody has expressed any significant issues with either the approach or content of the document.
(11) There is one non-RFC reference, but this document is reasonable for a normative reference.
(12) The document does not require any formal review.
(13) All references are appropriately marked as normative or informative.
(14) All normative references are in a good state.
(15) All normative references are considered to be stable. There is one external reference to the Unicode Standard.
(16) Karen and I have had a discussion on this. It is not clear that any documents need to be tagged as being updated. The document is marked as updating RFC 7519 (JSON Web Token) and is not marked as updating RFC 7515 (JSON Web Signature). The update to RFC 7519 consists of saying - do not use this document. RFC 7515 was not updated because the IANA registry was used instead. This should allow us to not update the JWS document.
(17) The consistency of the body and the IANA consideration has been checked as as the registration template against the registry.
(18) The document does not define any new IANA registries.
(19) There are no formal language sections for this document.