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

Brian Campbell <bcampbell@pingidentity.com> Wed, 23 April 2014 22:47 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C0D1A070B for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.577
X-Spam-Level:
X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9gw1DgMN1nd for <oauth@ietfa.amsl.com>; Wed, 23 Apr 2014 15:47:03 -0700 (PDT)
Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8A60D1A029F for <oauth@ietf.org>; Wed, 23 Apr 2014 15:47:03 -0700 (PDT)
Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKU1hC4WTXJ5Yone3SSwhynX02diEOMSYJ@postini.com; Wed, 23 Apr 2014 15:46:58 PDT
Received: by mail-ig0-f178.google.com with SMTP id hn18so185580igb.17 for <oauth@ietf.org>; Wed, 23 Apr 2014 15:46:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=etajoBNcCzqv/1eyyj0PR3422MgThxDj/5PRC/+vz8I=; b=PnY/SeSbcIT8zSpo7OOQvlkl0cCnz5C8IE0Yip+X3FJX6IYEBd6i53pUKCdFAUjTgK a/81LC3HcH7qACautvO9TqaiJZV60xSEZAmEsOq282JuTB0QO1bNFIuKi7fHs8Ncmq2k T9XHAIxvsg9Aw1Zqct8CLd0ApJKJ21l/anW93hPkxvxjpaRjItTKinYfSSRXutor5MCG T+vutxJMO+nMuYPRct3a+/3Hxh3R9HdpaqcrHkgEe9xFDunF7ahdJfDnJapvSMZBMHn1 USV3+SS8ncJiBkqcBXUe+NjSNpoZokENoLvhoLvB1mYO/UkuKiDadjmPxvF73QXCN+Ng f7zw==
X-Gm-Message-State: ALoCoQlpmWdFvtBV8gUNAkYrbLPa9OfTcLJdq1jKfhqvsm0k1i4Wcl4KwWy2js105/Xm5Vja3em4zPXyR326/zYuufPg/NRfFFOSTOcTTub6WDZ6GAHciLiRkEYJisAjK+tiPLnkQzMa
X-Received: by 10.50.49.109 with SMTP id t13mr84259ign.2.1398293217637; Wed, 23 Apr 2014 15:46:57 -0700 (PDT)
X-Received: by 10.50.49.109 with SMTP id t13mr84254ign.2.1398293217524; Wed, 23 Apr 2014 15:46:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.240.201 with HTTP; Wed, 23 Apr 2014 15:46:27 -0700 (PDT)
In-Reply-To: <5357AA4C.8080707@gmx.net>
References: <5357AA4C.8080707@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 23 Apr 2014 16:46:27 -0600
Message-ID: <CA+k3eCR5LKBugDicdAdGRx7Z+G_a7Rdh4=NCY9v0ye-vyncWzQ@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=047d7bdc123485dd8804f7bd8202
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Mv5PDv8LxHgVzD6USsDWIz0VlF4
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 22:47:07 -0000

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:
http://openid.net/specs/openid-connect-core-1_0.html#IDToken


On Wed, Apr 23, 2014 at 5:55 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> 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:
>
> https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/shepherd-writeups/Writeup_OAuth_JWT.txt
>
> 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
> http://openid.net/developers/libraries/
> (scrowl down to the 'JWT/JWS/JWE/JWK/JWA Implementations' section)
>
> An Excel document providing additional details can be found here:
> http://www.oauth-v2.org/wp-content/uploads/2014/04/JWT-Implementations.xlsx
>
> 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
>
> http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-oauth-json-web-token
>
>
> 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 http://www.ietf.org/tools/idnits/ 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>