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 >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
