Skip to main content

JSON Web Key (JWK)
RFC 7517

Revision differences

Document history

Date Rev. By Action
2022-04-01
41 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
41 (System) Notify list changed from jose-chairs@ietf.org, draft-ietf-jose-json-web-key@ietf.org to (None)
2015-05-21
41 (System) IANA registries were updated to include RFC7517
2015-05-19
41 (System) RFC published
2015-05-06
41 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7517">AUTH48-DONE</a> from AUTH48
2015-04-20
41 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7517">AUTH48</a> from RFC-EDITOR
2015-03-25
41 (System) RFC Editor state changed to RFC-EDITOR from REF
2015-03-24
41 (System) RFC Editor state changed to REF from EDIT
2015-01-26
41 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-23
41 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2015-01-23
41 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2015-01-20
41 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-19
41 (System) RFC Editor state changed to EDIT
2015-01-19
41 (System) Announcement was received by RFC Editor
2015-01-16
41 (System) IANA Action state changed to In Progress
2015-01-16
41 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-01-16
41 Cindy Morgan IESG has approved the document
2015-01-16
41 Cindy Morgan Closed "Approve" ballot
2015-01-16
41 Cindy Morgan Ballot approval text was generated
2015-01-16
41 Cindy Morgan Ballot writeup was changed
2015-01-16
41 Michael Jones New version available: draft-ietf-jose-json-web-key-41.txt
2015-01-13
40 Michael Jones New version available: draft-ietf-jose-json-web-key-40.txt
2014-12-30
39 Michael Jones New version available: draft-ietf-jose-json-web-key-39.txt
2014-12-09
38 Michael Jones New version available: draft-ietf-jose-json-web-key-38.txt
2014-12-02
37 Pete Resnick
[Ballot comment]
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this …
[Ballot comment]
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this WG has actually fulfilled its charter with regard to this document set. The WG was supposed to produce a "JSON syntax that can be used by applications to describe secure data objects". I don't believe it did that. Instead, it produced a compact serialization for a particular purpose and then backed into a JSON syntax. The compact serialization drove the effort and produced IMO a substandard JSON serialization. I don't believe that (reliable) interoperable implementations of the JSON serialization will be possible using this document set. However, there is at least rough consensus that these documents are usable as-is, and I don't think there's anything to be gained by holding them up any further.

I hope the WG will adopt some of the remaining comments, but my intention is not to discuss this any further. If you wish to address any of the comments and need clarification, I'm glad to help with that.

------

4/5:

There was a discussion about the "The member names within a JWK MUST be unique" paragraphs, and a proposal to fix them. No fixing was done.

4.1: The second paragraph is unnecessary and should be removed. Also, "use" is unnecessary given "key_ops" and should be removed.

4.6 (and 4.7-4.9):

  If other members
  are present, the contents of those members MUST be semantically
  consistent with the related fields in the first certificate.

This is a pretty silly use of MUST. If the answer to the question, "Why might
someone do otherwise?" is "Because they're an idiot", you probably don't need
the MUST.

5:

  Implementations SHOULD ignore JWKs within a JWK Set that use "kty"
  (key type) values that are not understood by them, are missing
  required members, or for which values are out of the supported
  ranges.

I don't understand that SHOULD. This is completely dependent on what the
implementation is doing. Unknown key types might be ignorable, but they might
be vitally important. Why is this not a MAY?

5.1: Strike the last sentence. It's silly.

7: The first two sentences of the first paragraph and the first sentence of the
second paragraph should be moved under Security Considerations; that's what
this is. I'd delete the rest, as the encryption of any JSON object is handled
by JWE.

You might mention the content type somewhere, but the way it is in the document
now is way overdone, with the whole "MUST...unless construction. Simply make it:

  The content type of "jwk+json" can be used for "cty" header of the JWE.

if you must have something.
2014-12-02
37 Pete Resnick Ballot comment text updated for Pete Resnick
2014-11-19
37 Michael Jones New version available: draft-ietf-jose-json-web-key-37.txt
2014-11-03
36 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss
2014-10-24
36 Michael Jones New version available: draft-ietf-jose-json-web-key-36.txt
2014-10-21
35 Stephen Farrell
[Ballot comment]

Cleared kid case-sensitivity point about inclusion of DNS names
based on text added to signature doc. Thanks for that.

As a comment I …
[Ballot comment]

Cleared kid case-sensitivity point about inclusion of DNS names
based on text added to signature doc. Thanks for that.

As a comment I do think a reference from here to there or
re-stating the point here would be good. But its ok if you prefer
not.

I didn't check the comments below.

---

4.8: I'd prefer if sha-256 had been the default/shorter of
these. But whatever.

4.8/4.9: the disconnect with DANE and other specs that use
HASH(SPKI) as a thumbprint is a pity (but can be fixed
later). How'd that happen?

8: "make sense" still isn't useful;-) I've noted that on the
algs draft though so won't repeat more.

C.9: Huh? Needs a ref to compact rep which isn't defined
here.

As with other JOSE drafts, there was a substantial thread on
the secdir review that I didn't have time to follow but I'm
ok that Kathleen's been on top of that.
2014-10-21
35 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2014-10-17
35 Michael Jones New version available: draft-ietf-jose-json-web-key-35.txt
2014-10-16
34 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-10-14
34 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-10-14
34 Michael Jones IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-10-14
34 Michael Jones New version available: draft-ietf-jose-json-web-key-34.txt
2014-10-02
33 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-10-02
33 Cindy Morgan Changed consensus to Yes from Unknown
2014-10-02
33 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-10-02
33 Ted Lemon
[Ballot comment]
I'm not sure whether I need to complain about this, but the following seems underspecified:

  UTF8(STRING) denotes the octets of the UTF-8 …
[Ballot comment]
I'm not sure whether I need to complain about this, but the following seems underspecified:

  UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
  of STRING.

  ASCII(STRING) denotes the octets of the ASCII [USASCII]
  representation of STRING.

The issue is that we don't know what STRING is.  Is it 32-bit unicode?  Is it ASCII?  What does it mean to have ASCII(unicode string)?  Is ASCII(STRING) an assertion that STRING is representable as ASCII?
2014-10-02
33 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-10-02
33 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from No Record
2014-10-02
33 Stephen Farrell
[Ballot discuss]

nearly a nit, but would impact code so a discuss to
make sure we get it right...

4.5: saying kid is case sensitive …
[Ballot discuss]

nearly a nit, but would impact code so a discuss to
make sure we get it right...

4.5: saying kid is case sensitive precludes use of DNS names
there or introduces bugs if those are used.  Since DNS names
are the primary way we distinguish things on the Internet,
that seems odd. I don't think that you need to say
case-insensitive here but that you might want to say that DNS
names SHOULD be [lower|upper]cased before being used in kid
parameters.
2014-10-02
33 Stephen Farrell
[Ballot comment]

4.8: I'd prefer if sha-256 had been the default/shorter of
these. But whatever.

4.8/4.9: the disconnect with DANE and other specs that use …
[Ballot comment]

4.8: I'd prefer if sha-256 had been the default/shorter of
these. But whatever.

4.8/4.9: the disconnect with DANE and other specs that use
HASH(SPKI) as a thumbprint is a pity (but can be fixed
later). How'd that happen?

8: "make sense" still isn't useful;-) I've noted that on the
algs draft though so won't repeat more.

C.9: Huh? Needs a ref to compact rep which isn't defined
here.

As with other JOSE drafts, there was a substantial thread on
the secdir review that I didn't have time to follow but I'm
ok that Kathleen's been on top of that.
2014-10-02
33 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2014-10-01
33 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-10-01
33 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-10-01
33 Pete Resnick
[Ballot comment]
Given my concerns with the other documents in this series, I'm not yet willing to ballot No Objection on this document. So I …
[Ballot comment]
Given my concerns with the other documents in this series, I'm not yet willing to ballot No Objection on this document. So I will Abstain, at least for the moment. We'll see how the rest of the discussion goes.

Comments directly on this document:

4/5:

  The member names within a JWK MUST be unique; recipients MUST either
  reject JWKs with duplicate member names or use a JSON parser that
  returns only the lexically last duplicate member name, as specified
  in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].

That first MUST is bogus. You are allowing them not to be unique in the rest of the sentence. And it's not clear what you mean by "recipients" here. Sounds like you mean "parsers" or "interpreters". If it were me, I'd stick to the "MUST be unique" and be done with it, but either way this paragraph needs fixing.

4.1: The second paragraph is redundant given the first paragraph; I'd delete it.

And why do you need "use" at all given that you've got "key_ops"?

4.5:

  The structure of the "kid" value is
  unspecified.

You should at least mention that this is a string. "The 'kid' value is a text string, but it's structure is otherwise unspecified." Or something like that.

4.6 (and 4.7-4.9):

  If other members
  are present, the contents of those members MUST be semantically
  consistent with the related fields in the first certificate.

This is a pretty silly use of MUST. If the answer to the question, "Why might someone do otherwise?" is "Because they're an idiot", you probably don't need the MUST.

5:

  Implementations SHOULD ignore JWKs within a JWK Set that use "kty"
  (key type) values that are not understood by them, are missing
  required members, or for which values are out of the supported
  ranges.

I don't understand that SHOULD. This is completely dependent on what the implementation is doing. Unknown key types might be ignorable, but they might be vitally important. Why is this not a MAY?

5.1: Strike the last sentence. It's silly.

7: The first two sentences of the first paragraph and the first sentence of the second paragraph should be moved under Security Considerations; that's what this is. I'd delete the rest, as the encryption of any JSON object is handled by JWE.

You might mention the content type somewhere, but the way it is in the document now is way overdone, with the whole "MUST...unless construction. Simply make it:

  The content type of "jwk+json" can be used for "cty" header of the JWE.

if you must have something.
2014-10-01
33 Pete Resnick [Ballot Position Update] New position, Abstain, has been recorded for Pete Resnick
2014-10-01
33 Richard Barnes
[Ballot discuss]
Section 4.3.
"The "use" and "key_ops" JWK members SHOULD NOT be used together."
Did the WG discuss how these could combine?  What was …
[Ballot discuss]
Section 4.3.
"The "use" and "key_ops" JWK members SHOULD NOT be used together."
Did the WG discuss how these could combine?  What was the outcome of that discussion?  This could be an important point for interoperability.  For example, WebCrypto enforces them both, so it will break if it gets a key with "use" and "key_ops" set to inconsistent values.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-pss-operations

Section 8.
"[TBD]@ietf.org"
This needs to be populated before approval.  I don't know what's customary here, but "jose@ietf.org" is an obvious candidate.
2014-10-01
33 Richard Barnes
[Ballot comment]
Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Section 4.
It might be worth being …
[Ballot comment]
Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Section 4.
It might be worth being explicit (here or elsewhere):
"A JWK MUST NOT contain algorithm-specific members for key type other the one specified in its "kty" attribute."

Section 4.1.
"cryptographic algorithm family used with the key"
"... such as "RSA" or "EC"."

Section 4.7.
"base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
It seems unpleasant for implementations to have to support two flavors of base64, especially since this doesn't use PEM directly.  Did the WG discuss just using BASE64URL?

Section 9.1.
It might help here to note that technologies like PKIX and JWT can allow relying parties to verify the provenance of a key and binding of attributes to it.
2014-10-01
33 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2014-10-01
33 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-10-01
33 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-10-01
33 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-01
33 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Record from No Objection
2014-10-01
33 Kathleen Moriarty IESG state changed to IESG Evaluation from Waiting for Writeup
2014-09-30
33 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-09-29
33 Scott Brim Request for Telechat review by GENART Withdrawn. Reviewer: Scott Brim.
2014-09-29
33 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-09-28
33 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-09-25
33 Jean Mahoney Request for Telechat review by GENART is assigned to Scott Brim
2014-09-25
33 Jean Mahoney Request for Telechat review by GENART is assigned to Scott Brim
2014-09-25
33 Michael Jones IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-09-25
33 Michael Jones New version available: draft-ietf-jose-json-web-key-33.txt
2014-09-25
32 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-09-25
32 Kathleen Moriarty Ballot has been issued
2014-09-25
32 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2014-09-25
32 Kathleen Moriarty Created "Approve" ballot
2014-09-25
32 Kathleen Moriarty Ballot writeup was changed
2014-09-24
32 Brian Haberman Removed telechat returning item indication
2014-09-23
32 Michael Jones IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-09-23
32 Michael Jones New version available: draft-ietf-jose-json-web-key-32.txt
2014-09-04
31 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent.
2014-09-04
31 Kathleen Moriarty Telechat date has been changed to 2014-10-02 from 2014-09-18
2014-09-03
31 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-09-01
31 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahalingam Mani
2014-09-01
31 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahalingam Mani
2014-08-29
31 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-08-29
31 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-json-web-key-31.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments: …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-json-web-key-31.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, there are five actions which IANA must complete.

IANA understands that, for the new registries created below, the following registry maintenance rules will be applied:

Values are registered on a Specification Required [RFC5226] basis after a two-week review period on the [TBD]@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.

Registration requests must be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for access token type: example"). The Designated Expert will contact IANA when a request has been approved.

First, in a location to be determined, IANA will create a registry called the JSON Web Key Parameters Registry.  The registration rules for the new registry are noted above. The registry records the parameter name, the key type(s) that the parameter is used with, and a reference to the specification that defines it.  It also records whether the parameter conveys public or private information.

There are initial registrations in this new registry as follows:

+---------------+--------------+-----------------------+-----------------------+
| Parameter    | Used with    | Parameter Information |                      |
| Name          | "kty" value  | Class                | Reference            |
+---------------+--------------+-----------------------+-----------------------+
| kty          | *            | Public                | [ RFC-to-be ]        |
| use          | *            | Public                | [ RFC-to-be ]        |
| key_ops      | *            | Public                | [ RFC-to-be ]        |
| alg          | *            | Public                | [ RFC-to-be ]        |
| kid          | *            | Public                | [ RFC-to-be ]        |
| x5u          | *            | Public                | [ RFC-to-be ]        |
| x5c          | *            | Public                | [ RFC-to-be ]        |
| x5t          | *            | Public                | [ RFC-to-be ]        |
| x5t+S256      | *            | Public                | [ RFC-to-be ]        |
+---------------+--------------+-----------------------+-----------------------+

Second, also in a location to be determined, IANA will create a registry called the JSON Web Key Use Registry.  The registration rules for the new registry are noted above.  The registry records the public key use value and a reference to the specification that defines it.

There are initial registrations in this new registry as follows:

+--------------+-----------------------+
| Use Member  |                      |
| Value        | Reference            |
+--------------+-----------------------+
| sig          | [ RFC-to-be ]        |
| enc          | [ RFC-to-be ]        |
+--------------+-----------------------+

Third, also in a location to be determined, IANA will create a registry called the JSON Web Key Operations Registry.  The registration rules for the new registry are noted above.  The registry records the key operation value and a reference to the specification that defines it.

There are initial registrations in this new registry as follows:

+-------------------+-------------------------+
| Key Operation    |                        |
| Value            | Reference              |
+-------------------+-------------------------+
| sign              | [ RFC-to-be ]          |
| verify            | [ RFC-to-be ]          |
| encrypt          | [ RFC-to-be ]          |
| decrypt          | [ RFC-to-be ]          |
| wrapKey          | [ RFC-to-be ]          |
| unwrapKey        | [ RFC-to-be ]          |
| deriveKey        | [ RFC-to-be ]          |
| deriveBits        | [ RFC-to-be ]          |
+-------------------+-------------------------+

Fourth, also in a location to be determined, IANA will create a registry called the JSON Web Key Set Parameters Registry.  The registration rules for the new registry are noted above.  The registry records the parameter name and a reference to the specification that defines it.

There are initial registrations in this new registry as follows:

+----------------+-----------------------+
| Parameter      |                      |
| Name          | Reference            |
+----------------+-----------------------+
| keys          | [ RFC-to-be ]        |
+----------------+-----------------------+

Fifth, in the application media types registry located at:

http://www.iana.org/assignments/media-types/

two new media types are to be registered as follows:

Name: application/jwk+json
Reference: [ RFC-to-be ]

Name: application/jwk-set+json
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-08-26
31 Kathleen Moriarty Placed on agenda for telechat - 2014-09-18
2014-08-21
31 Jean Mahoney Request for Last Call review by GENART is assigned to Scott Brim
2014-08-21
31 Jean Mahoney Request for Last Call review by GENART is assigned to Scott Brim
2014-08-21
31 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stephen Kent
2014-08-21
31 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stephen Kent
2014-08-20
31 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-08-20
31 Cindy Morgan
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <jose@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <jose@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-jose-json-web-key-31.txt> (JSON Web Key (JWK)) 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)'
  <draft-ietf-jose-json-web-key-31.txt> 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 2014-09-03. 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


  A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data
  structure that represents a cryptographic key.  This specification
  also defines a JSON Web Key Set (JWK Set) JSON data structure that
  represents a set of JWKs.  Cryptographic algorithms and identifiers
  for use with this specification are described in the separate JSON
  Web Algorithms (JWA) specification and IANA registries defined by
  that specification.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ballot/


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


2014-08-20
31 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-08-20
31 Kathleen Moriarty Last call was requested
2014-08-20
31 Kathleen Moriarty Ballot approval text was generated
2014-08-20
31 Kathleen Moriarty Ballot writeup was generated
2014-08-20
31 Kathleen Moriarty IESG state changed to Last Call Requested from AD Evaluation
2014-08-20
31 Kathleen Moriarty Last call announcement was generated
2014-08-14
31 Karen O'Donoghue
JSON Web Encryption (JWE) writeup:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this …
JSON Web Encryption (JWE) writeup:

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

This document is being requested for publication as a Proposed Standard. The
document was produced with the expectation that it would be widely used in
conjunction with the JSON Web Algorithms (JWA), JSON Web Signature (JWS), and
JSON Web Key (JWK) documents as part of a suite of documents providing security 
services for JSON. As such, it is reasonable for these documents to progress on the
standards track. The intended status is shown on the title page. 

(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, JSON Web Encryption (JWE), represents encrypted content using
JavaScript Object Notation (JSON) based data structures.

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.

Document Quality:

This document has been reviewed and revised many times. There are multiple
implementations of this document. Some of these are listed at:
https://openid.net/developers/libraries/ (see the JWT/JWS/JWE/JWK/JWA
Implementations section). There were no specific external expert reviews
conducted; however, the WGLC notification was sent to the W3C WebCrypto
working group.

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. Note, the
document shepherd did not validate the examples in the appendices.

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

This document doesnÕt require any special reviews beyond those planned during the
IESG review process. As a security specification, additional security reviews during
this process are expected.

(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
with two serializations for JWE objects. This specification has been implemented
and adopted in some communities (most especially OpenID).

(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 WG consensus, however there are some issues for
which consensus was difficult with strong proponents on both sides of the issues.

(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 following nit was identified. This nit is related to downrefs to algorithm
documents and are discussed further in (15).

** Downref: Normative reference to an Informational RFC: RFC 1951

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

There are no formal review criteria for this document.

(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 is one down-reference to an information document.  This is an algorithm
document so this is normal procedure. 
 
        RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3

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

These documents are all first time documents.  They 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).

This document adds entries to the following IANA registry:
      JSON Web Signature and Encryption Header Parameters (defined in JWS)

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

This document does not create any new IANA registries.

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

2014-07-04
31 Michael Jones New version available: draft-ietf-jose-json-web-key-31.txt
2014-07-01
30 Michael Jones New version available: draft-ietf-jose-json-web-key-30.txt
2014-07-01
29 Kathleen Moriarty IESG state changed to AD Evaluation from Publication Requested
2014-06-20
29 Michael Jones New version available: draft-ietf-jose-json-web-key-29.txt
2014-06-20
28 Michael Jones New version available: draft-ietf-jose-json-web-key-28.txt
2014-06-10
27 Michael Jones New version available: draft-ietf-jose-json-web-key-27.txt
2014-04-30
26 Michael Jones New version available: draft-ietf-jose-json-web-key-26.txt
2014-04-12
25 Jim Schaad
This represents a combined writeup for four documents

JWA - draft-ietf-jose-json-web-algorithms
JWE - draft-ietf-jose-json-web-encryption
JWK - draft-ietf-jose-json-web-key
JWS - draft-ietf-jose-json-web-signature

********************************

(1) These documents are …
This represents a combined writeup for four documents

JWA - draft-ietf-jose-json-web-algorithms
JWE - draft-ietf-jose-json-web-encryption
JWK - draft-ietf-jose-json-web-key
JWS - draft-ietf-jose-json-web-signature

********************************

(1) These documents are being requested for progress at at Proposed Standard.  The documents were produced in the expectation that they will be widely used to provide security services for JSON documents, as such it is reasonable for these documents to progress on the standards track.

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

(JWA) This document, the JSON Web Algorithms (JWA) specification, registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.

(JWE) This document, JSON Web Encryption (JWE), represents encrypted content using JavaScript Object Notation (JSON) based data structures.

(JWK) This document, JSON Web Key (JWK), is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs.

(JWS) This document, JSON Web Signature (JWS), represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. 

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.

(JWA) The question of what cryptographic algorithms should be included was somewhat difficult as it is for any process trying to determine which algorithms should be included. The considerations included what is implemented, available, broadly used, and adequate from a security perspective. The issue of algorithms that are potentially less desirable but more broadly implemented was considered.

Document Quality:

There are multiple implementations of all four documents. There were no specific external expert reviews conducted. The WGLC notification was sent to the W3C WebCrypto working group.

Personnel:

Karen O'Donoghue is acting as the Document Shepard.  Kathleen Morirty  is the Responsible Area Director

(3) The document shepherd has followed the working group process and reviewed the final documents and feels these documents are ready for IESG review. Further discussion and changes may result from IESG and IETF review, but the documents as they stand are ready for publication.

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

(5) JSON-Web-Signture and JSON-Web-Key register new Media Types.  A request for review has been sent to the media type review mailing list.

(6) The Document Shepherd is comfortable with these documents as a stable set of specifications that have been implemented and adopted in some communities (most especially OpenID). There has also been some attempt to coordinate with the W3C WebCrypto working group. The documents are not perfect, but they do represent the consensus of the working group. There is a minority contingent of recognized experts that believe there are a number of issues in the documents. However, these specifications have been widely implemented and deployed in the OpenID community.

(7) All authors have confirmed that they have dealt with all appropriate IPR disclosures.

(8) Certicom Corporation has filed an IPR discloser on draft-ietf-jose-json-web-algorithms and draft-ietf-jose-json-web-signature dealing with elliptical curve technologies.  These patents are the normal IPR disclosure from Certicom and received only a brief discussion. The group was notified of an additional possible patent from IBM, but no discloser was ever filed and no discussion was ever held on the patent. (The patent appears to be a mechanical transformation of XML digital signatures and mapping it onto JSON.)

(9) The majority of the documents represent a solid WG consensus, however there are some issues for which consensus was reached more by fatigue, with strong proponents on both sides of the issues.

(10) There have been no threats of anyone appealing the documents.

(11) The following nit errors were identified. These nits are all related to downrefs to algorithm documents and are discussed further in (15).

JWA
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2898
** Downref: Normative reference to an Informational RFC: RFC 3394
** Downref: Normative reference to an Informational RFC: RFC 6090

JWE
** Downref: Normative reference to an Informational RFC: RFC 1951

JWK
** Downref: Normative reference to an Historic RFC: RFC 1421
** Downref: Normative reference to an Informational RFC: RFC 2818

JWS
** Downref: Normative reference to an Historic RFC: RFC 1421
** Downref: Normative reference to an Informational RFC: RFC 2818


(12) JSON-Web-Signture and JSON-Web-Key register new Media Types.  A request for review has been sent to the media type review mailing list.

(13) All references are tagged as normative or informative.

(14) All normative references are on track for completion or are completed.

(15) There are a number of down-references to information documents.  These are all algorithm documents so this is normal procedure.  There is one down-reference to an Historic document.

JSON-Web-Algorithms:
        RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
        RFC 2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
        RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm
        RFC 6090 - Fundamental Elliptic Curve Cryptography Algorithms

JSON-Web-Encryption:
        RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3

JSON-Web-Key:
        RFC 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures  (Historic)
        RFC 2818 - HTTP Over TLS

JSON-Web-Signature:
        RFC 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
        RFC 2818 - HTTP Over TLS

(16) These documents are all first time documents.  They will not change the status of any existing documents.

(17) The chairs have walked through all of the documents to verify that all of the items that need to be registered have been called out in the IANA considerations section and that they are consistant between what is in the text and what is in the registration templates.  The WG was careful to try and call out the necessary information needed to do adaquate review on new items for the registry.

(18) All of the registries created by these documents are designated as requiring Expert Review.  The registries to be created are:

JSON-Web-Algorithms:
* JSON Web Signature Encryption Algorithm Registery
* JSON Web Encryption Compression Algorithm Registry
* JSON Web Key Types Registry
* JSON Web Key Elliptic Curve Registry

JSON-Web-Key:
* JSON Web Key Parameters Registry
* JSON Web Key Use Registry
* JSON Web Key Operations Registry
* JSON Web Key Set Parameters Registry

JSON-Web-Signature:
* JSON Web Signature and Encryption Header Parameters Registry

At this time it is known that there will be new allocations from the W3C WebCrypto group and the OAuth WG.  The major concern is going to be the fact that if the authors of the current drafts are selected as the reviewers, it is not going to lead to independent reviewers.  However it is not clear where the pool of reviewers should be drawn from if the current authors are excluded.

(19) There are no formal language sections in these documents.
2014-04-12
25 Jim Schaad State Change Notice email list changed to jose-chairs@tools.ietf.org, draft-ietf-jose-json-web-key@tools.ietf.org
2014-04-12
25 Jim Schaad Responsible AD changed to Kathleen Moriarty
2014-04-12
25 Jim Schaad IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2014-04-12
25 Jim Schaad IESG state changed to Publication Requested
2014-04-12
25 Jim Schaad IESG process started in state Publication Requested
2014-04-12
25 Jim Schaad Changed document writeup
2014-04-12
25 Jim Schaad Document shepherd changed to Karen O'Donoghue
2014-04-12
25 Jim Schaad Intended Status changed to Proposed Standard from None
2014-03-31
25 Michael Jones New version available: draft-ietf-jose-json-web-key-25.txt
2014-03-18
24 Michael Jones New version available: draft-ietf-jose-json-web-key-24.txt
2014-03-03
23 Michael Jones New version available: draft-ietf-jose-json-web-key-23.txt
2014-03-02
22 Michael Jones New version available: draft-ietf-jose-json-web-key-22.txt
2014-02-14
21 Michael Jones New version available: draft-ietf-jose-json-web-key-21.txt
2014-01-25
20 Jim Schaad IETF WG state changed to In WG Last Call from WG Document
2014-01-20
20 Michael Jones New version available: draft-ietf-jose-json-web-key-20.txt
2013-12-29
19 Michael Jones New version available: draft-ietf-jose-json-web-key-19.txt
2013-11-12
18 Michael Jones New version available: draft-ietf-jose-json-web-key-18.txt
2013-10-07
17 Michael Jones New version available: draft-ietf-jose-json-web-key-17.txt
2013-09-15
16 Michael Jones New version available: draft-ietf-jose-json-web-key-16.txt
2013-09-03
15 Michael Jones New version available: draft-ietf-jose-json-web-key-15.txt
2013-07-29
14 Michael Jones New version available: draft-ietf-jose-json-web-key-14.txt
2013-07-15
13 Michael Jones New version available: draft-ietf-jose-json-web-key-13.txt
2013-07-12
12 Michael Jones New version available: draft-ietf-jose-json-web-key-12.txt
2013-05-28
11 Michael Jones New version available: draft-ietf-jose-json-web-key-11.txt
2013-04-26
10 Michael Jones New version available: draft-ietf-jose-json-web-key-10.txt
2013-04-23
09 Michael Jones New version available: draft-ietf-jose-json-web-key-09.txt
2012-12-28
08 Michael Jones New version available: draft-ietf-jose-json-web-key-08.txt
2012-11-07
07 Michael Jones New version available: draft-ietf-jose-json-web-key-07.txt
2012-10-15
06 Michael Jones New version available: draft-ietf-jose-json-web-key-06.txt
2012-07-30
05 Michael Jones New version available: draft-ietf-jose-json-web-key-05.txt
2012-07-16
04 Michael Jones New version available: draft-ietf-jose-json-web-key-04.txt
2012-07-06
03 Michael Jones New version available: draft-ietf-jose-json-web-key-03.txt
2012-05-12
02 Michael Jones New version available: draft-ietf-jose-json-web-key-02.txt
2012-03-12
01 Michael Jones New version available: draft-ietf-jose-json-web-key-01.txt
2012-01-16
00 (System) New version available: draft-ietf-jose-json-web-key-00.txt