Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up
Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 25 April 2014 09:35 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 2CD6D1A0163 for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 02:35:56 -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 aw0t1qW4A8IX for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 02:35:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 240F41A0359 for <oauth@ietf.org>; Fri, 25 Apr 2014 02:35:53 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwW8p-1WyQLI0wTH-018KJQ; Fri, 25 Apr 2014 11:35:44 +0200
Message-ID: <535A29E7.6040505@gmx.net>
Date: Fri, 25 Apr 2014 11:24:55 +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>, oauth@ietf.org
References: <53577C73.2010201@gmx.net> <4E1F6AAD24975D4BA5B16804296739439A194E55@TK5EX14MBXC288.redmond.corp.microsoft.com> <535A21F3.4050306@gmail.com>
In-Reply-To: <535A21F3.4050306@gmail.com>
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==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FDet3ksy0rtq1vqJmvpNM6dvS4M
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 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: >> 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
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Mike Jones
- [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd W… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Chuck Mortimore
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Chuck Mortimore
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Sergey Beryozkin
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Sergey Beryozkin
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Antonio Sanso
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Chuck Mortimore
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Phil Hunt
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Justin Richer
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Bill Burke
- Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shephe… Nat Sakimura