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

Hannes Tschofenig <> Fri, 25 April 2014 09:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CD6D1A0163 for <>; Fri, 25 Apr 2014 02:35:56 -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 aw0t1qW4A8IX for <>; Fri, 25 Apr 2014 02:35:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 240F41A0359 for <>; Fri, 25 Apr 2014 02:35:53 -0700 (PDT)
Received: from [] ([]) by (mrgmx101) with ESMTPSA (Nemesis) id 0LwW8p-1WyQLI0wTH-018KJQ; Fri, 25 Apr 2014 11:35:44 +0200
Message-ID: <>
Date: Fri, 25 Apr 2014 11:24:55 +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: Sergey Beryozkin <>,
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jFptSGgVKamPRfCGpbgal8ojRKMaMNX0k"
X-Provags-ID: V03:K0:jWhFtp0uwF8H+i2sakmfIvA/Zh97WDIbhZUqFuc8w52XkCccLMF XwzMiOWbYUW63fKh+lzKmnpoLkyZ5NOIcT5bf7b8WZShQ5lj2dhKLpnUbJn/LANHgnXFi9a 6rcfuIGUSHD0/9H6afUHxj8yfMm+Sqoj7PkO+Fr2nxyUUtZXP4jU5+c1+B2yrbRe8MjsurH gJCnMDmL1/gmchs3gxBKQ==
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: Fri, 25 Apr 2014 09:35:56 -0000

The implementation and deployment status of JWT is certainly good.
For this write-up it would, however, be interesting to know what the
implementation status of the JWT bearer assertion spec is.

On 04/25/2014 10:50 AM, Sergey Beryozkin wrote:
> On 24/04/14 23:41, Mike Jones wrote:
>> I am aware of these implementations:
>>     Microsoft Azure Active Directory: 
>>     Google Service Account:
>> I believe that Ping Identity and Salesforce also have implementations,
>> but I'll let Brian and Chuck authoritatively speak to those.
> Here is some info about open source projects:
> Apache Oltu has a good support for working with JWT, believe Spring
> Security has it (I haven't tried) and JBoss KeyCloak team works with
> JWT, work for supporting JWT Bearer is in progress in Apache CXF (a
> month or so away).
> There will be a pretty good coverage for it...
> Sergey
>>                 -- Mike
>> -----Original Message-----
>> From: OAuth [] On Behalf Of Hannes
>> Tschofenig
>> Sent: Wednesday, April 23, 2014 1:40 AM
>> To:
>> Subject: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up
>> 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 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
>> (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
> _______________________________________________
> OAuth mailing list