Shepherd writeup
rfc7520-08

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is an Informational RFC request

(2) Approval Announcement:

Technical Summary

  This document provides a set of examples for the standards
  created by the JOSE (JavaScript Object Signing And Encryption)
  working group.  The document includes examples of JOSE being
  used for signing, encrypting, and authenticating texts, as
  well as how public key pairs and symmetric keys can be encoded.

  Examples are given for both the Compact and JSON serialization
  formats.

Working Group Summary

  The document was completely non-controversial.  The only discussions on the document dealt with which cases were missing from the document.

Document Quality

  All of the Compact serializations have been validated by
  at least two people.  The JSON serializations are equivalent
  to the compact serializations, but have not had the same 
  testing level.

Personnel

  The document shepherd is Jim Schaad, the AD is Kathleen Moriarty.

(3) I have read the document from front to back twice looking for awkwardness in the working, missing cases and other such items.  The -05 version should have all of my feedback incorporated in it and that is the version that should be reviewed. 

The document is a constructed document from boilerplate, thus I have done a detailed check on one instance of each boilerplate and just scanned the rest.

I have not yet done an implementation to check the JSON encodings, however I have looked that the compact encodings and the JSON encodings look to have the same values and the JSON encoding has the correct set of fields.  The compact encodings have been independently checked for correctness.

(4) It would be nice to have programmatic validation of the JSON serialization examples.  However, the compact and JSON serializations were generated at the same time and from the same data so that the mathmatics are known to be correct.  It is possible to do visual checks that the strings are the same, I have done this in a spot check manner and have found no issues.

(5) The document should not need to have any broader review than it currently has gotten.  The only suggestion that has occurred during review has been a request to have an example that includes a password that needs to have more complicated processing done to it, that is to include PRECIS processing.

(6) I have no concerns about this document that either the AD or IESG need to be made aware of.

(7) Question has not been asked of the authors yet.  Will do when final version is published.
    The expected answer is no.
Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

(8) No IPR disclosures have been filed on this document.

(9) The document has been non-controversial and has wide support for release.

(10) There has been no controversy for this document.

(11) There re no nits in the -03 version, but a final check on the final document needs to be done.

(12) No external formal review is required for this document.

(13) All references are informative.  This is appropriate for the document.

(14) All references from this document are informative.  No normative references exist.

(15) There are no normative references.

(16) This is first time document and will not change the status of any other document.

(17) The document has no IANA considerations.  I have verified that this is appropriate.

(18) The document has no IANA considerations.  

(19) There are no formal language sections of the document.
Back