Salesforce supports this > On Apr 25, 2014, at 6:11 AM, John Bradley <ve7...@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.tschofe...@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-boun...@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
