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

[John Bradley <[e-mail]>]

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 <[e-mail]> 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:[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
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth