JSON Web Key (JWK) Thumbprint
draft-ietf-jose-jwk-thumbprint-08

[Ballot comment]
This draft chooses the wrong input to the hash function. Other
specifications, even those that do not otherwise use ASN.1 use
the SubjectPublicKeyInfo ASN.1 structure for that. I raised
that point in the WG and during IETF LC but was in the rough.
Nonetheless, this will I believe need to be done over later
when or if there is a need to identify a public key in a
cross-protocol or similar context. That's a waste of effort
for no good reason. The world won't end though.

[Ballot comment]
-- Section 6 --

  This specification adds to the instructions to the Designated Experts
  for the following IANA registries, all of which are in the JSON
  Object Signing and Encryption (JOSE) protocol category [IANA.JOSE]:
  o  JSON Web Key Types
  o  JSON Web Key Elliptic Curve
  o  JSON Web Key Parameters

Because you're changing the DE instructions, either this document needs to "update" 7517 and 7518 (where those registries are defined), or it needs to update the registries to add itself to the reference field ("[RFC7518][RFCxxxx]").  And in either case, it needs to make it clear in the introduction that Section 6 provides additional instructions to the designated experts for those three registries.  Otherwise, it's too easy for DEs for those registries not to notice this update.  [I know the current DEs are well aware of it.  But that's not the point.]

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type of
RFC? Is this type of RFC indicated in the title page header?

The document is being requested for publication as a Proposed Standard.  The
document is the consensus of the working group, but the working group was
somewhat ambivalent on which publication track to pursue. It could be argued that
this is just an algorithm description and thus should be Informational. In the end,
the working group maintained the current approach of Proposed Standard, but the
working group is willing to defer to the IESG if they prefer another approach.

(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:

This document defines a method for computing a hash value over a JSON Web Key
structure.  The document describes what the subset of fields in a key to be used are,
the method of creating a canonical form for those fields, and how to convert the
resulting UNICODE string into a byte sequence appropriate for hashing.

Working Group Summary:

The document has clear working group consensus for publication, and has been
reviewed by several WG participants since its initial adoption as a working group
item. There was some discussion over the form and content of the string to be
hashed.  Some people advocated for the use of the current X.509 SPKI structure and
some over use a string that was not a JSON structure.  This discussion ended without
conclusion and thus the original proposal advanced.

Document Quality:

This document has been reviewed and revised a few times. Several individuals from
the OpenID Connect community have indicated that they have implemented the
protocol.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is the
Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the
final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were
performed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The scope of the document is currently limited to the JSON Web documents from the
JOSE working group.  As such there has been sufficient review for this purpose.  In
the event that there is a push to use something such as DANE with this element, it
might need more review both on the content and the question of the use a hash of
the SPKI structure instead.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event, if the
WG has discussed those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable specification.
This specification has been implemented and adopted in some communities (most
especially OpenID). The only issue here is the question of what the correct
serialization content is and if sufficient fields have been included.  The people who
are planning to use the item immediately are comfortable with the content.

(7) 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?

All authors have confirmed that they have no relevant IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures filed for this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as
a whole understand and agree with it?

The document represents a solid if somewhat ambivalent WG consensus. The
document meets an immediate need of the community currently using the JOSE
specifications.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate
checks are not enough; this check needs to be thorough.

ID nits were checked on the -06 version of the document. The results were as
follows: 
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).

There were two comments associated with Normative references to documents
external to the IETF (from NIST and the Unicode Consortium). Both are appropriate
normative references.
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'

There are two comments and a warning that are all related to body text  using [ ]
being incorrectly identified as a reference.
-- Looks like a reference, but probably isn't: '1' on line 451
-- Looks like a reference, but probably isn't: '0' on line 451
== Missing Reference: 'specified ' is mentioned on line 450, but not defined

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

This document does not require any formal review.

(13) Have all references within this document been identified as either normative or
informative?
All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are two documents that are tagged as down references.  Both of these
documents should be fine.  They are:
    * The UNIODE Standard from the Unicode Consortium
    * The Secure Hash Standard from NIST

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of this document
to the other RFCs is discussed. If this information is not in the document, explain
why the WG considers it unnecessary.

This document is a first time document.  It will not change the status of any existing
documents.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

There are no new IANA registries in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-jwk-thumbprint-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JSON Web Key (JWK) Thumbprint) to Proposed Standard


The IESG has received a request from the Javascript Object Signing and
Encryption WG (jose) to consider the following document:
- 'JSON Web Key (JWK) Thumbprint'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a method for computing a hash value over a
  JSON Web Key (JWK).  It defines which fields in a JWK are used in the
  hash computation, the method of creating a canonical form for those
  fields, and how to convert the resulting Unicode string into a byte
  sequence to be hashed.  The resulting hash value can be used for
  identifying or selecting the key represented by the JWK that is the
  subject of the thumbprint.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type of
RFC? Is this type of RFC indicated in the title page header?

The document is being requested for publication as a Proposed Standard.  The
document is the consensus of the working group, but the working group was
somewhat ambivalent on which publication track to pursue. It could be argued that
this is just an algorithm description and thus should be Informational. In the end,
the working group maintained the current approach of Proposed Standard, but the
working group is willing to defer to the IESG if they prefer another approach.

(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:

This document defines a method for computing a hash value over a JSON Web Key
structure.  The document describes what the subset of fields in a key to be used are,
the method of creating a canonical form for those fields, and how to convert the
resulting UNICODE string into a byte sequence appropriate for hashing.

Working Group Summary:

The document has clear working group consensus for publication, and has been
reviewed by several WG participants since its initial adoption as a working group
item. There was some discussion over the form and content of the string to be
hashed.  Some people advocated for the use of the current X.509 SPKI structure and
some over use a string that was not a JSON structure.  This discussion ended without
conclusion and thus the original proposal advanced.

Document Quality:

This document has been reviewed and revised a few times. Several individuals from
the OpenID Connect community have indicated that they have implemented the
protocol.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is the
Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the
final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were
performed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The scope of the document is currently limited to the JSON Web documents from the
JOSE working group.  As such there has been sufficient review for this purpose.  In
the event that there is a push to use something such as DANE with this element, it
might need more review both on the content and the question of the use a hash of
the SPKI structure instead.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event, if the
WG has discussed those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable specification.
This specification has been implemented and adopted in some communities (most
especially OpenID). The only issue here is the question of what the correct
serialization content is and if sufficient fields have been included.  The people who
are planning to use the item immediately are comfortable with the content.

(7) 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?

All authors have confirmed that they have no relevant IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures filed for this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as
a whole understand and agree with it?

The document represents a solid if somewhat ambivalent WG consensus. The
document meets an immediate need of the community currently using the JOSE
specifications.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate
checks are not enough; this check needs to be thorough.

The document shepherd has talked to the editor about the brevity of the abstract. A
slightly more detailed abstract will be added during the next revision cycle, but it
wasn’t deemed necessary to hold up the IESG review for that addition.

ID nits were checked on the -05 version of the document. The results were as
follows: 
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

There were two comments associated with Normative references to documents
external to the IETF (from NIST and the Unicode Consortium). Both are appropriate
normative references.
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'

There are two comments and a warning that are all related to body text  using [ ]
being incorrectly identified as a reference.
-- Looks like a reference, but probably isn't: '1' on line 404
-- Looks like a reference, but probably isn't: '0' on line 404
== Missing Reference: 'specified ' is mentioned on line 403, but not defined

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

This document does not require any formal review.

(13) Have all references within this document been identified as either normative or
informative?
All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are two documents that are tagged as down references.  Both of these
documents should be fine.  They are:
    * The UNIODE Standard from the Unicode Consortium
    * The Secure Hash Standard from NIST

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of this document
to the other RFCs is discussed. If this information is not in the document, explain
why the WG considers it unnecessary.

This document is a first time document.  It will not change the status of any existing
documents.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

There are no new IANA registries in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type of
RFC? Is this type of RFC indicated in the title page header?

The document is being requested for publication as a Proposed Standard.  The
document is the consensus of the working group, but the working group was
somewhat ambivalent on which publication track to pursue. It could be argued that
this is just an algorithm description and thus should be Informational. In the end,
the working group maintained the current approach of Proposed Standard, but the
working group is willing to defer to the IESG if they prefer another approach.

(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:

This document defines a method for computing a hash value over a JSON Web Key
structure.  The document describes what the subset of fields in a key to be used are,
the method of creating a canonical form for those fields, and how to convert the
resulting UNICODE string into a byte sequence appropriate for hashing.

Working Group Summary:

The document has clear working group consensus for publication, and has been
reviewed by several WG participants since its initial adoption as a working group
item. There was some discussion over the form and content of the string to be
hashed.  Some people advocated for the use of the current X.509 SPKI structure and
some over use a string that was not a JSON structure.  This discussion ended without
conclusion and thus the original proposal advanced.

Document Quality:

This document has been reviewed and revised a few times. Several individuals from
the OpenID Connect community have indicated that they have implemented the
protocol.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is the
Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the
final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were
performed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The scope of the document is currently limited to the JSON Web documents from the
JOSE working group.  As such there has been sufficient review for this purpose.  In
the event that there is a push to use something such as DANE with this element, it
might need more review both on the content and the question of the use a hash of
the SPKI structure instead.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event, if the
WG has discussed those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable specification.
This specification has been implemented and adopted in some communities (most
especially OpenID). The only issue here is the question of what the correct
serialization content is and if sufficient fields have been included.  The people who
are planning to use the item immediately are comfortable with the content.

(7) 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?

All authors have confirmed that they have no relevant IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures filed for this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as
a whole understand and agree with it?

The document represents a solid if somewhat ambivalent WG consensus. The
document meets an immediate need of the community currently using the JOSE
specifications.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate
checks are not enough; this check needs to be thorough.

The document shepherd has talked to the editor about the brevity of the abstract. A
slightly more detailed abstract will be added during the next revision cycle, but it
wasn’t deemed necessary to hold up the IESG review for that addition.

ID nits were checked on the -05 version of the document. The results were as
follows: 
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

There were two comments associated with Normative references to documents
external to the IETF (from NIST and the Unicode Consortium). Both are appropriate
normative references.
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'

There are two comments and a warning that are all related to body text  using [ ]
being incorrectly identified as a reference.
-- Looks like a reference, but probably isn't: '1' on line 404
-- Looks like a reference, but probably isn't: '0' on line 404
== Missing Reference: 'specified ' is mentioned on line 403, but not defined

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

This document does not require any formal review.

(13) Have all references within this document been identified as either normative or
informative?
All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are two documents that are tagged as down references.  Both of these
documents should be fine.  They are:
    * The UNIODE Standard from the Unicode Consortium
    * The Secure Hash Standard from NIST

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of this document
to the other RFCs is discussed. If this information is not in the document, explain
why the WG considers it unnecessary.

This document is a first time document.  It will not change the status of any existing
documents.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

There are no new IANA registries in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type of
RFC? Is this type of RFC indicated in the title page header?

The document is being requested for publication as a Proposed Standard.  The
document is the consensus of the working group, but the working group was
somewhat ambivalent on which publication track to pursue. It could be argued that
this is just an algorithm description and thus should be Informational. In the end,
the working group maintained the current approach of Proposed Standard, but the
working group is willing to defer to the IESG if they prefer another approach.

(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:

This document defines a method for computing a hash value over a JSON Web Key
structure.  The document describes what the subset of fields in a key to be used are,
the method of creating a canonical form for those fields, and how to convert the
resulting UNICODE string into a byte sequence appropriate for hashing.

Working Group Summary:

The document has clear working group consensus for publication, and has been
reviewed by several WG participants since its initial adoption as a working group
item. There was some discussion over the form and content of the string to be
hashed.  Some people advocated for the use of the current X.509 SPKI structure and
some over use a string that was not a JSON structure.  This discussion ended without
conclusion and thus the original proposal advanced.

Document Quality:

This document has been reviewed and revised a few times. Several individuals from
the OpenID Connect community have indicated that they have implemented the
protocol.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is the
Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the
final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were
performed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The scope of the document is currently limited to the JSON Web documents from the
JOSE working group.  As such there has been sufficient review for this purpose.  In
the event that there is a push to use something such as DANE with this element, it
might need more review both on the content and the question of the use a hash of
the SPKI structure instead.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event, if the
WG has discussed those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable specification.
This specification has been implemented and adopted in some communities (most
especially OpenID). The only issue here is the question of what the correct
serialization content is and if sufficient fields have been included.  The people who
are planning to use the item immediately are comfortable with the content.

(7) 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?

All authors have confirmed that they have no relevant IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures filed for this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as
a whole understand and agree with it?

The document represents a solid if somewhat ambivalent WG consensus. The
document meets an immediate need of the community currently using the JOSE
specifications.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate
checks are not enough; this check needs to be thorough.

The document shepherd has talked to the editor about the brevity of the abstract. A
slightly more detailed abstract will be added during the next revision cycle, but it
wasn’t deemed necessary to hold up the IESG review for that addition.

ID nits were checked on the -04 version of the document. The results were as
follows: 
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--).

There were two comments associated with Normative references to documents
external to the IETF (from NIST and the Unicode Consortium). Both are appropriate
normative references.
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'

There was one outdated reference that will be updated during the next revision of
the document.
== Outdated reference: draft-ietf-json-i-json has been published as RFC 7493

There are two comments and a warning that are all related to body text  using [ ]
being incorrectly identified as a reference.
-- Looks like a reference, but probably isn't: '1' on line 404
-- Looks like a reference, but probably isn't: '0' on line 404
== Missing Reference: 'specified ' is mentioned on line 403, but not defined

(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

This document does not require any formal review.

(13) Have all references within this document been identified as either normative or
informative?
All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are two documents that are tagged as down references.  Both of these
documents should be fine.  They are:
    * The UNIODE Standard from the Unicode Consortium
    * The Secure Hash Standard from NIST

(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of this document
to the other RFCs is discussed. If this information is not in the document, explain
why the WG considers it unnecessary.

This document is a first time document.  It will not change the status of any existing
documents.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

There are no new IANA registries in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.