Oracle also has an implementation. Phil
@independentid www.independentid.com phil.h...@oracle.com On Apr 25, 2014, at 3:13 AM, Antonio Sanso <asa...@adobe.com> wrote: > Hi Torsten, > > Adobe also has an implementation. > > regards > > antonio > > On Apr 25, 2014, at 7:26 AM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > >> Deutsche Telekom also has an implementation. >> >> regards, >> Torsten. >> >> >> -------- Ursprüngliche Nachricht -------- >> Von: Chuck Mortimore >> Datum:25.04.2014 01:31 (GMT+01:00) >> An: Mike Jones >> Cc: oauth@ietf.org >> Betreff: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up >> >> Salesforce Implementation: >> https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US >> >> >> On Thu, Apr 24, 2014 at 3:41 PM, Mike Jones <michael.jo...@microsoft.com> >> 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. >> >> -- 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
