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

Chuck Mortimore <cmortimore@salesforce.com> Fri, 25 April 2014 14:06 UTC

Return-Path: <cmortimore@salesforce.com>
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 949E11A04CD for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 07:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KlPtcPUnVJFO for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 07:06:53 -0700 (PDT)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 605DD1A04C8 for <oauth@ietf.org>; Fri, 25 Apr 2014 07:06:53 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id vb8so4282208obc.15 for <oauth@ietf.org>; Fri, 25 Apr 2014 07:06:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc:content-type; bh=1t93zu8SBpAm/ncQKM1a7B/oPcIJVPg3Jy0IP7bhng4=; b=H6jmAP04wat3AWfAAPmT1Pkm40HPs9WicLCmum8HdTC7TDxPWS/N+J4SpdAYcbPd3V kj85E9lDV3wxI/tWzn+u38Kt1UKDLBstZMOyh4ncYeH8k2fJbcYvSkS9AdG//uUpnj4F +Ont7V/CkPeCaLkLtVBY/0ScPwLydZaJWQwHsLZGUI0frp+FjlAsxLj2GH7D8FRs3z74 cV4SDqyNXg0xbpPttD51GzhP+kxt3AodqtHKgb3EJp44qHOeFj0AP32RXf6r+dJNok8K QWl00/SufEYukfGOJk/yG3XSF04JVp3rD9Z0/eLQyY0HbjEDktUuDhoBwUZSndamGkLY SdYg==
X-Gm-Message-State: ALoCoQn+ftQUgz6WwrGoLjRRD2Vm2R091ZHzuJHmbCkCka6HLfCkcBA7igWNn8UmAlNobZWNZpaz
X-Received: by 10.60.131.172 with SMTP id on12mr7198956oeb.18.1398434806732; Fri, 25 Apr 2014 07:06:46 -0700 (PDT)
References: <53577C73.2010201@gmx.net> <4E1F6AAD24975D4BA5B16804296739439A194E55@TK5EX14MBXC288.redmond.corp.microsoft.com> <535A21F3.4050306@gmail.com> <535A29E7.6040505@gmx.net> <535A2E98.2000804@gmail.com> <535A544C.80100@gmx.net> <BEECE591-AC74-4A2C-AE0F-63606E6C7E6D@ve7jtb.com>
From: Chuck Mortimore <cmortimore@salesforce.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <BEECE591-AC74-4A2C-AE0F-63606E6C7E6D@ve7jtb.com>
Date: Fri, 25 Apr 2014 07:06:42 -0700
Message-ID: <1061532531353586658@unknownmsgid>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G6hblQNL_wCrybw_QQR00-_mdok
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 14:06:56 -0000

Salesforce supports this

> On Apr 25, 2014, at 6:11 AM, John Bradley <ve7jtb@ve7jtb.com> 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 <hannes.tschofenig@gmx.net> 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:
>>>>>> 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
>>
>> _______________________________________________
>> 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