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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 25 April 2014 12:36 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 0130F1A04B7 for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 05:36:52 -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 CCgmoph7lwxM for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 05:36:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id B84761A04C1 for <oauth@ietf.org>; Fri, 25 Apr 2014 05:36:45 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MZgdm-1WKLnc2LfS-00LZVO; Fri, 25 Apr 2014 14:36:38 +0200
Message-ID: <535A544C.80100@gmx.net>
Date: Fri, 25 Apr 2014 14:25:48 +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: Sergey Beryozkin <sberyozkin@gmail.com>
References: <53577C73.2010201@gmx.net> <4E1F6AAD24975D4BA5B16804296739439A194E55@TK5EX14MBXC288.redmond.corp.microsoft.com> <535A21F3.4050306@gmail.com> <535A29E7.6040505@gmx.net> <535A2E98.2000804@gmail.com>
In-Reply-To: <535A2E98.2000804@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hQfOa7KjmVrHhMSS3pWu6PBwS3dI2gl5x"
X-Provags-ID: V03:K0:ZeyEtI/2XeoUpaW4kDoEHRoMg13HtpQtDDqPlhGHKEvLIYEBIJl nd39xYoT6R4t/udJav/24uQALH9CqaOgm9ET5lP2V0mRC1ARsdVMMX2itDW7edHbodq0IzE IVVJbN0g21sXhH064xYrav9ngopdHz78+i8GRkgF62pyQjfHUG902CwXPhVogPw361zB+TH nG3O5Dm6TUomGN9DYdhHg==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LaqkulMW4sQ5LOHQovLQdwlMmR4
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: Fri, 25 Apr 2014 12:36:52 -0000

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:
>>>> http://azure.microsoft.com/en-us/services/active-directory/
>>>>      Google Service Account:
>>>> https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>>>
>>>> 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 [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
>>>> Tschofenig
>>>> Sent: Wednesday, April 23, 2014 1:40 AM
>>>> To: oauth@ietf.org
>>>> 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
>>>> 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
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>