Skip to main content

Shepherd writeup

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

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.


  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

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

(18) The document has no IANA considerations.

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