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

Brian Campbell <> Thu, 24 April 2014 12:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A34901A01B9 for <>; Thu, 24 Apr 2014 05:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Status: No, score=-3.578 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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8qq2gQakZqUu for <>; Thu, 24 Apr 2014 05:26:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 670A41A01AD for <>; Thu, 24 Apr 2014 05:26:01 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 24 Apr 2014 05:25:55 PDT
Received: by with SMTP id rp18so2201811iec.5 for <>; Thu, 24 Apr 2014 05:25:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5GPcOVDhZiOIi3WzvRb18XvUATuhQv40OwNb+uMF02A=; b=J6NN+3/kcJG/wb1/LFK6gBAcgs4JRQgdKdRcPHpbNyub+1BIj1nbDPEhKfyeWyihmI ph6mrBhiS8/anVBJl5hFpl55wH9cz125FmZEcp2+cQgq4Iovw9g8ItuVj++xnrSEzPxz RuO5MxVTrzGqyssrqdT/LFKQ4AEkHmPZGoInAB07gbkBbymWlFR5e9ns/nkmNM8e2D6t aXJ3Ssi6+LHSMQEGctpUtBc1/uPuX/ZGLTPNyHbS6JgWiUEoPGdWdXLJL55AMcHlv2Gp M3r+gXIh9KY7zQBdvbmwkyUxqRExhEbQGOE26ncbbMQWWyRCXEyzfGx7uEOyp+xBA5RJ kvXQ==
X-Gm-Message-State: ALoCoQnY1Cm0CnDyQ9gKysWt/JdXtcKR/DRIuKcgSoaq11fs+cOPRk0Jvh7U75IYR3GHclAFx42IPH8G266BTQPM9C3cTO4XHeS1cb/rjNeYCkFzedvEBavp1yVU8QSd80qQ+e6mcEsP
X-Received: by with SMTP id g4mr9308183igc.9.1398342355257; Thu, 24 Apr 2014 05:25:55 -0700 (PDT)
X-Received: by with SMTP id g4mr9308168igc.9.1398342355096; Thu, 24 Apr 2014 05:25:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Apr 2014 05:25:25 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Thu, 24 Apr 2014 06:25:25 -0600
Message-ID: <>
To: Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="089e013c661459d98c04f7c8f350"
Cc: "" <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer 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 12:26:05 -0000

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>"

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

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

On Wed, Apr 23, 2014 at 2:40 AM, Hannes Tschofenig <> 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
> 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:
> (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
> 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
> (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.
> (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