Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 24 April 2014 07:12 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 91FE71A0314 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 00:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivlGBL1w-m6i for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 00:12:50 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 97E151A00AE for <oauth@ietf.org>; Thu, 24 Apr 2014 00:12:50 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MKu9E-1WdDpr35Ga-0004DM; Thu, 24 Apr 2014 09:12:44 +0200
Message-ID: <5358B907.3030905@gmx.net>
Date: Thu, 24 Apr 2014 09:11:03 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
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 <bcampbell@pingidentity.com>
References: <5357AA4C.8080707@gmx.net> <CA+k3eCR5LKBugDicdAdGRx7Z+G_a7Rdh4=NCY9v0ye-vyncWzQ@mail.gmail.com>
In-Reply-To: <CA+k3eCR5LKBugDicdAdGRx7Z+G_a7Rdh4=NCY9v0ye-vyncWzQ@mail.gmail.com>
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==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/rhNNsSOzCxzklP4BnePTrAP7QTs
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: 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: > 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 <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > >
- [OAUTH-WG] draft-ietf-oauth-json-web-token-19 She… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19… John Bradley
- [OAUTH-WG] FW: draft-ietf-oauth-json-web-token-19… Mike Jones