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

Justin Richer <> Fri, 25 April 2014 16:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D047D1A0584 for <>; Fri, 25 Apr 2014 09:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cdtiufjEmHSL for <>; Fri, 25 Apr 2014 09:21:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 344821A065E for <>; Fri, 25 Apr 2014 09:21:47 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id A5D1C2350036; Fri, 25 Apr 2014 12:21:40 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG ( []) by (Postfix) with ESMTP id 750872350038; Fri, 25 Apr 2014 12:21:40 -0400 (EDT)
Received: from [] ( by IMCCAS04.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Fri, 25 Apr 2014 12:21:40 -0400
Message-ID: <>
Date: Fri, 25 Apr 2014 12:20:59 -0400
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Chuck Mortimore <>, John Bradley <>
References: <> <> <> <> <> <> <> <1061532531353586658@unknownmsgid>
In-Reply-To: <1061532531353586658@unknownmsgid>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
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: Fri, 25 Apr 2014 16:21:53 -0000

MITREid Connect supports this mode, also (client authentication with a 
client-generated JWT assertion).

We also have support for a subset of the JWT Bearer Assertion for 
renewing ID tokens, but as far as I know nobody's running that bit of 
code in reality and I can't guarantee it actually does anything.

  -- Justin

On 04/25/2014 10:06 AM, Chuck Mortimore wrote:
> Salesforce supports this
>> On Apr 25, 2014, at 6:11 AM, John Bradley <> wrote:
>> The JWT bearer spec is used in Connect for authenticating clients with asymmetric credentials.
>> I don't know at the moment how many server implementations support that as it is not MTI.
>> I know it is on the Ping roadmap but not currently in shipping product.
>> John B.
>>> On Apr 25, 2014, at 9:25 AM, Hannes Tschofenig <> wrote:
>>> Hi Sergey,
>>> no, your comment wasn't off-topic and I agree that more widespread
>>> support of the JWT spec will also have a positive impact on the JWT
>>> bearer implementation / deployment status.
>>> draft-ietf-oauth-jwt-bearer spec requires the JWT to be used in a
>>> specific way. It does, however, make sense to indicate the JWT
>>> implementation situation in the write-up.
>>> Ciao
>>> Hannes
>>>> On 04/25/2014 11:44 AM, Sergey Beryozkin wrote:
>>>>> On 25/04/14 10:24, Hannes Tschofenig wrote:
>>>>> 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.
>>>> Was I off-topic ? Sorry about it, I thought it would be encouraging for
>>>> experts to see the general status, the wider JWT is supported the more
>>>> likely the count of JWT Bearer assertion adopters will go up
>>>> Cheers, Sergey
>>>>>> 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
>>> _______________________________________________
>>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list