Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up

Hannes Tschofenig <> Thu, 24 April 2014 07:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91FE71A0314 for <>; Thu, 24 Apr 2014 00:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ivlGBL1w-m6i for <>; Thu, 24 Apr 2014 00:12:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97E151A00AE for <>; Thu, 24 Apr 2014 00:12:50 -0700 (PDT)
Received: from [] ([]) by (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1WdDpr35Ga-0004DM; Thu, 24 Apr 2014 09:12:44 +0200
Message-ID: <>
Date: Thu, 24 Apr 2014 09:11:03 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Brian Campbell <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="0jrosNpFI0KCmOdc8FKQHVCGPw4mqx5Qo"
X-Provags-ID: V03:K0:4p1CE5GgmZCz6inGP1cuB7kl2WgD6uvHo14ymD2zBTY90btfKxu VtTZy1bFkSxcbPDnbX/Ff10KqyqQHGaTzDXpPuXXj2rqVj7qpfKhseti7gQkiiDEGx99vG3 Lt84sB2NzkjE8jsgXQ241wo4N4qegVzEZ5FHdo7OXJ03TRF1dNNLOkhIXEUhf5pR72+TQsJ S9xE02lTn0wDDXnU79/sQ==
Cc: "" <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Apr 2014 07:12:53 -0000

Thanks, Brian. I will add this aspect to the write-up.

On 04/24/2014 12:46 AM, Brian Campbell wrote:
> While OAuth access tokens are a valuable application of JWT, might it
> also be worthwhile to mention that JWT can and will be useful in other
> contexts? Connect's ID Token is one such example:
> On Wed, Apr 23, 2014 at 5:55 AM, Hannes Tschofenig
> < <>> wrote:
>     Hi all,
>     I am working on the shepherd writeup for the JWT. Here are a few
>     questions:
>     - To the document authors: Please confirm that any and all appropriate
>     IPR disclosures required for full conformance with the provisions of BCP
>     78 and BCP 79 have already been filed.
>     - To all: I have included various pointers to implementations in the
>     write-up. Maybe there are others that should be included. If so, please
>     let me know.
>     - To all: Please also go through the text to make sure that I correctly
>     reflect the history and the status of this document.
>     Here is the latest version of the write-up:
>     Ciao
>     Hannes
>     PS: Here is the copy-and-paste text:
>     --------
>     Writeup for "JSON Web Token (JWT)" <draft-ietf-oauth-json-web-token-19>
>     (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 RFC type is 'Standards Track' and the type is indicated in the title
>     page. This document defines the syntax and semantic of information
>     elements.
>     (2) The IESG approval announcement includes a Document Announcement
>     Write-Up. Please provide such a Document Announcement Write-Up. Recent
>     examples can be found in the "Action" announcements for approved
>     documents. The approval announcement contains the following sections:
>     Technical Summary:
>        JSON Web Token (JWT) is a compact URL-safe means of representing
>        claims to be transferred between two parties.  The claims in a JWT
>        are encoded as a JavaScript Object Notation (JSON) object that is
>        used as the payload of a JSON Web Signature (JWS) structure or as the
>        plaintext of a JSON Web Encryption (JWE) structure, enabling the
>        claims to be digitally signed or MACed and/or encrypted.
>     Working Group Summary:
>     Was there anything in WG process that is worth noting? For example, was
>     there controversy about particular points or were there decisions where
>     the consensus was particularly rough?
>     This document was uncontroversial. It allows OAuth deployments to use a
>     standardized access token format, which increases interoperability of
>     OAuth-based deployments.
>     Document Quality:
>     This document has gone through many iterations and has received
>     substantial feedback.
>     A substantial number of implementations exist, as documented at
>     (scrowl down to the 'JWT/JWS/JWE/JWK/JWA Implementations' section)
>     An Excel document providing additional details can be found here:
>     Personnel:
>     The document shepherd is Hannes Tschofenig and the responsible area
>     director is Kathleen Moriarty.
>     (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 draft authors believe that this document is ready for publication.
>     The document has received review comments from working group members,
>     and from the OAuth working group chairs. Implementations exist and they
>     have tested for interoperability as part of the OpenID Connect interop
>     events.
>     (4) Does the document Shepherd have any concerns about the depth or
>     breadth of the reviews that have been performed?
>     This document has gotten enough feedback from the working group.
>     (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.
>     Since the OAuth working group develops security protocols any feedback
>     from the security community is always appreciated.
>     The JWT document heavily depends on the work in the JOSE working group
>     since it re-uses the JWE and the JWS specifications.
>     (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 shepherd has no concerns with this document.
>     (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?
>     [[Confirmation from the authors required.]]
>     (8) Has an IPR disclosure been filed that references this document? If
>     so, summarize any WG discussion and conclusion regarding the IPR
>     disclosures.
>     Two IPRs have been filed for the JWT specification this document relies
>     on, see
>     There was no discussion regarding those two IPRs on the mailing list.
>     (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 working group has consensus to publish this document.
>     (10) Has anyone threatened an appeal or otherwise indicated extreme
>     discontent? If so, please summarise the areas of conflict in separate
>     email messages to the Responsible Area Director. (It should be in a
>     separate email because this questionnaire is publicly available.)
>     No appeal or extreme discontent has been raised.
>     (11) Identify any ID nits the Document Shepherd has found in this
>     document. (See and the Internet-Drafts
>     Checklist). Boilerplate checks are not enough; this check needs to be
>     thorough.
>     The shepherd has checked the nits. The shepherd has not verified the
>     examples for correctness.
>     (12) Describe how the document meets any required formal review
>     criteria, such as the MIB Doctor, media type, and URI type reviews.
>     The document does not require a formal review even though it contains
>     JSON-based examples.
>     (13) Have all references within this document been identified as either
>     normative or informative?
>     Yes.
>     (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?
>     There are various JOSE documents that have not been published as RFCs
>     yet. As such, this document cannot be published before the respective
>     JOSE documents are finalized.
>     (15) Are there downward normative references references (see RFC 3967)?
>     If so, list these downward references to support the Area Director in
>     the Last Call procedure.
>     The document contains a reference to
>        [ECMAScript]
>                   Ecma International, "ECMAScript Language Specification,
>                   5.1 Edition", ECMA 262, June 2011.
>     which might require a downref.
>     RFC 6755 is also a downref.
>     (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.
>     The publication of this document does not change the status of other
>     RFCs.
>     (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).
>     The document creates a new registry for JWT claims and populates this
>     registry with values.
>     It also registers values into two existing registries, namely into
>      * the RFC 6755 created OAuth URN registry, and
>      * the media type registry
>     (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.
>     The newly created JWT claims registry requires expert review for future
>     allocations. Guidance is given in the document.
>     The document shepherd volunteers to become an expert review.
>     (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 examples in the document that use a JSON-based encoding. The
>     document shepherd has reviewed those examples but has not verified the
>     correctness of the cryptographic operations.
>     _______________________________________________
>     OAuth mailing list
> <>