Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 24 April 2014 12:38 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 0C0371A01B3 for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:38:06 -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 3NwOZE5CoO5G for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 05:38:02 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB931A01B0 for <oauth@ietf.org>; Thu, 24 Apr 2014 05:38:01 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M34eJ-1WwTrB0W19-00stLg; Thu, 24 Apr 2014 14:37:54 +0200
Message-ID: <535904B5.4040800@gmx.net>
Date: Thu, 24 Apr 2014 14:33:57 +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: <53577C73.2010201@gmx.net> <CA+k3eCSjNJVLGH=jz7OmcsASiZoWkY+UNwunG8D_OdB9+Vx3Lg@mail.gmail.com>
In-Reply-To: <CA+k3eCSjNJVLGH=jz7OmcsASiZoWkY+UNwunG8D_OdB9+Vx3Lg@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0thXcG0kn5Pb9VBRqBOId4BqO9UIVTmAE"
X-Provags-ID: V03:K0:FggydJPCC4v/jtgcRx1RumHxyT4XqLLDdbONVyAx9DXcd4Gcoyw Q59PvrqO5JINqrActfPqzZO/UJmjcaKVft4oL61q5Qh9D1cf3e902OyuYgO/wUy2rrevXoK 0DMXvFhu0C+lRHABP0VZeiiNVpoUOkAro9Mx9e26XDTJaJbSs5rR3wWyoc1z/+ZLWmBDSV+ oqBn4/+qubvD2p6nAsCLw==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lh0PehkcSTrkjFp96mopLBQ5OzQ
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer 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 12:38:06 -0000

Hi Brian,

thanks for the quick response.

On 04/24/2014 02:25 PM, Brian Campbell wrote:
> I do not have, nor am I aware of any, IPR on any of the technology in
> the document.
> 
> Couple of little things on the writeup:
> 
> "Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client
> Authentication and Authorization Grants" <draft-ietf-oauth-saml2-
> bearer-08>"  -> should have "<draft-ietf-oauth-*jwt*-bearer-08>"

Fixed.

> 
> Does the answer to 14 need more explanation? There normative references
> to drafts draft-ietf-oauth-assertions and
> draft-ietf-oauth-json-web-token (which depends on the JOSE work) but
> they are all expected to be advanced soon.

Added text.

> 
> Related, the answer for 15 has "There are the following dependencies:"
> at the end with nothing following it.
> 
Fixed.

Updated version is here:
https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/shepherd-writeups/Writeup_OAuth_JWT-Assertion-Profile.txt


Ciao
Hannes

> 
> 
> On Wed, Apr 23, 2014 at 2:40 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 bearer document. The
>     shepherd write-ups for the assertion draft and the SAML bearer document
>     have been completed a while ago already, see
>     http://www.ietf.org/mail-archive/web/oauth/current/msg12410.html
> 
>     A few requests:
> 
>     - 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: Are you aware of implementations of this specification? If so,
>     I would like to reference them in my write-up.
> 
>     - 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 most recent version of the write-up:
>     https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/shepherd-writeups/Writeup_OAuth_JWT-Assertion-Profile.txt
> 
> 
>     (The copy-and-paste of the full version is below.)
> 
>     Ciao
>     Hannes
> 
>     PS: Note that I have send a mail about a pending issue to the list. In
>     response to my question I will update the write-up accordingly.
> 
>     ----
> 
>     Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client
>     Authentication and Authorization Grants"
>     <draft-ietf-oauth-saml2-bearer-08>
> 
>     (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 an instantiation for the OAuth assertion
>     framework using JSON Web Tokens.
> 
>     (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 specification defines the use of a JSON Web Token (JWT) Bearer
>        Token as a means for requesting an OAuth 2.0 access token as well as
>        for use as a means of client authentication.
> 
>     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 belongs to the OAuth assertion document bundle consisting
>     of the abstract OAuth assertion framework, and the SAML assertion
>     profile. Due to the use of the JSON-based encoding of the assertion it
>     also relies on the work in the JOSE working group (such as JWE/JWS)
>     indirectly through the use of the JWT. This document has intentionally
>     been kept in sync with the SAML-based version.
> 
>     Document Quality:
> 
>     This document has gone through many iterations and has received
>     substantial feedback.
> 
>     [[Add implementation list 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 had received review comments from working group
>     members, and from the OAuth working group chairs. These review comments
>     have been taken into account.
> 
>     (4) Does the document Shepherd have any concerns about the depth or
>     breadth of the reviews that have been performed?
> 
>     This document has gotten feedback from the working group and given the
>     focused use cases it has received adequate review.
> 
>     (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.
> 
>     (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.
> 
>     No IPR disclosures have been filed on this document. However, 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
> 
> 
>     (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.
> 
>     (12) Describe how the document meets any required formal review
>     criteria, such as the MIB Doctor, media type, and URI type reviews.
> 
>     There is no such review necessary.
> 
>     (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?
> 
>     Yes.
> 
>     (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.
> 
>     RFC 6755 defines the urn:ietf:params:oauth URN and is an Informational
>     RFC. A downref is required.
> 
>     However, this document depends on the completion of the abstract OAuth
>     assertion framework and on the JWT specification.
>     There are the following dependencies:
> 
>     (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 registers two sub-namespaces to the urn:ietf:params:oauth
>     URN established with RFC 6755.
> 
>     (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 document only adds entries to existing registries and does not
>     define any new 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 only snippets of message exchanges and JWT assertion
>     structures, which are based on JSON, used in the examples. There is no
>     pseudo code contained in the document that requires validation.
> 
> 
> 
> 
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
> 
>