Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

[Chuck Mortimore <[e-mail]>]

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 <[e-mail]>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:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, April 23, 2014 1:40 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>