(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:
Technical Summary
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.
Document Quality
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.
Personnel
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.