Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up
Bill Burke <bburke@redhat.com> Fri, 25 April 2014 18:52 UTC
Return-Path: <bburke@redhat.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 2A2741A03CE for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 11:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.174
X-Spam-Level:
X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 q0chrkSPN-H6 for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 11:52:03 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C06581A031E for <oauth@ietf.org>; Fri, 25 Apr 2014 11:52:03 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3PIpukG031336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <oauth@ietf.org>; Fri, 25 Apr 2014 14:51:57 -0400
Received: from [10.10.50.202] (vpn-50-202.rdu2.redhat.com [10.10.50.202]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3PIpt2M026983 for <oauth@ietf.org>; Fri, 25 Apr 2014 14:51:56 -0400
Message-ID: <535AAECE.502@redhat.com>
Date: Fri, 25 Apr 2014 14:51:58 -0400
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: oauth@ietf.org
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> <1061532531353586658@unknownmsgid>
In-Reply-To: <1061532531353586658@unknownmsgid>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yOwETqxARyAW9PLqkjf_y0o17ZI
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 18:52:08 -0000
Red Hat Keycloak [1] only supports basic auth for client authentication as suggested in the OAuth 2 spec. But our access tokens are JWS signed JWTs. Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth [2]? Or is there another document I should be following? I'd like to see what other claims are being discussed related to JWT-based access tokens and may have some additional access token claims we've been experimenting with others might be interested in. Also, I'm not sure yet if we'll implement draft-ietf-oauth-jwt-bearer to authenticate clients. A lot of our initial users are more interested in public clients and/or the implicit flow as they are writing a lot of pure javascript apps served up by simple static web servers. [1] http://keycloak.org [2] http://tools.ietf.org/html/rfc6750 On 4/25/2014 10:06 AM, Chuck Mortimore wrote: > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
- 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