On Apr 24, 2014, at 7:32 PM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for doing = this, Hannes. I would suggest making the following = changes...

Change =93It= allows OAuth deployments to use a standardized access token format, = which increases interoperability of OAuth-based deployments=94 to =93It = defines a standard JSON-based security token format, increasing = interoperability both among OAuth deployments using it and in other = application contexts as well=94.

I would = change http://openid.net/developers/libraries/ to http://openid.net/developers/libraries/#jwt (adding the #jwt target = within the page).

I would = change =93The draft authors believe that this document is ready for = publication=94 to =93The document is ready for = publication=94.

I would = change the answer to (15) to say nothing about ECMAScript, since it is = not a downref, and to only say =93RFC 6755 is a downref, since 6755 is = informational.=94

I would = change =93The document shepherd volunteers to become an expert review=94 = to the following:

The = document shepherd and the author Michael Jones both volunteer to become = expert reviewers. Note that the document recommends that multiple = expert reviewers be appointed, with the following text (which also = appears in the JOSE documents):

   It is suggested that multiple = Designated Experts be appointed who are
   able = to represent the perspectives of different applications = using
   this specification, in order to enable = broadly-informed review of
   registration decisions. = In cases where a registration decision could
   be = perceived as creating a conflict of interest for a = particular
   Expert, that Expert should = defer to the judgment of the other
   = Expert(s).

I would = change =93The document shepherd has reviewed those examples but has not = verified the correctness of the cryptographic operations=94 to =93The = document shepherd has reviewed those examples but has not verified the = correctness of the cryptographic operations, however Brian Campbell has = done so=94.

Thanks = again for moving this forward!

          &= nbsp;           &nb= sp;            = ;            &= nbsp;            = -- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] = On Behalf Of Hannes Tschofenig
Sent: Thursday, April 24, 2014 12:11 = AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd = Write-up

Thanks, Brian. I will add this aspect to the = write-up.

On = 04/24/2014 12:46 AM, Brian Campbell wrote:
> While OAuth access tokens are a valuable = application of JWT, might it
> = also be worthwhile to mention that JWT can and will be useful in = other
> contexts? Connect's ID = Token is one such example:
> http= ://openid.net/specs/openid-connect-core-1_0.html#IDToken
>
>
> On = Wed, Apr 23, 2014 at 5:55 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net = <mailto:hannes.tschofenig@gmx.net= >> wrote:
>
>     Hi all,
>
>     I am working on the shepherd = writeup for the JWT. Here are a few
>     = questions:
>
>     - 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: I have included = various pointers to implementations in the
>     write-up. Maybe there = are others that should be included. If so, please
>     let me = know.
>
>     - 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 latest version of = the write-up:
>
> https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/ma= st
> = er/shepherd-writeups/Writeup_OAuth_JWT.txt
>
>     Ciao
>     = Hannes
>
>     PS: Here is the copy-and-paste = text:
>
>     = --------
>
>     Writeup for "JSON Web Token = (JWT)"
> = <draft-ietf-oauth-json-web-token-19>
>
>     (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 the syntax and semantic of information
>     = elements.
>
>     (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:
>
>        JSON Web = Token (JWT) is a compact URL-safe means of = representing
>        claims to be = transferred between two parties. The claims in a = JWT
>        are encoded = as a JavaScript Object Notation (JSON) object that = is
>        used as the = payload of a JSON Web Signature (JWS) structure or as = the
>        plaintext of = a JSON Web Encryption (JWE) structure, enabling the
>        = claims to be digitally signed or MACed and/or = encrypted.
>
>     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 was = uncontroversial. It allows OAuth deployments to use = a
>     = standardized access token format, which increases interoperability = of
>     = OAuth-based deployments.
>
>     Document = Quality:
>
>     This document has gone through = many iterations and has received
>     substantial = feedback.
>
>     A substantial number of = implementations exist, as documented at
>     http://openid.net/develop= ers/libraries/
>     (scrowl down to the = 'JWT/JWS/JWE/JWK/JWA Implementations' section)
>
>     An Excel document providing = additional details can be found here:
>
> http://www.oauth-v2.org/wp-content/uploads/2014/04/JWT-Implementatio= ns
> = .xlsx
>
>     = 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 = received review comments from working group = members,
>     and from the OAuth working = group chairs. Implementations exist and they
>     have tested for = interoperability as part of the OpenID Connect = interop
>     events.
>
>     (4) Does the document Shepherd = have any concerns about the depth or
>     breadth of the reviews that = have been performed?
>
>     This document has gotten = enough feedback from the working group.
>
>     (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.
>     The JWT document heavily = depends on the work in the JOSE working group
>     since it re-uses the = JWE and the JWS specifications.
>
>     (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.
>
>     Two IPRs have been filed for = the JWT specification this document relies
>     on, = see
>
> http://datatracker.ietf.org/ipr/search/?option=3Ddocument_se= arch&id=3Ddraf
> = t-ietf-oauth-json-web-token
>
>
>     There was no discussion = regarding those two IPRs on the mailing list.
>
>     (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/idnit= s/ and the Internet-Drafts
>     Checklist). Boilerplate checks = are not enough; this check needs to be
>     = thorough.
>
>     The shepherd has checked the = nits. The shepherd has not verified the
>     examples for = correctness.
>
>     (12) Describe how the document = meets any required formal review
>     criteria, such as the MIB = Doctor, media type, and URI type reviews.
>
>     The document does not require = a formal review even though it contains
>     JSON-based = examples.
>
>     (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?
>
>     There are various JOSE = documents that have not been published as RFCs
>     yet. As such, this = document cannot be published before the respective
>     JOSE documents are = finalized.
>
>     (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.
>
>     The document contains a = reference to
>
>        = [ECMAScript]
>         &nb= sp;         Ecma International, = "ECMAScript Language Specification,
>         &nb= sp;         5.1 Edition", ECMA = 262, June 2011.
>
>     which might require a = downref.
>
>     RFC 6755 is also a = downref.
>
>
>     (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 creates a new = registry for JWT claims and populates this
>     registry with = values.
>     It also registers values into = two existing registries, namely into
>      * the RFC 6755 created = OAuth URN registry, and
>      * the media type = registry
>
>     (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 newly created JWT claims = registry requires expert review for future
>     allocations. Guidance = is given in the document.
>     The document shepherd = volunteers to become an expert review.
>
>     (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 examples in the = document that use a JSON-based encoding. The
>     document shepherd has = reviewed those examples but has not verified the
>     correctness of the = cryptographic operations.
>
>
>
>     = _______________________________________________
>     OAuth mailing = list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/= mailman/listinfo/oauth
>
>

________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth