JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
draft-ietf-oauth-access-token-jwt-13

[Ballot comment]
My co-AD pretty much nailed it.  I would go further and say that her comment about "Why is this only SHOULD?" applies to a lot of the SHOULDs in here.  SHOULD presents a choice; why might an implementer reasonably not do any of the SHOULD things in here?

For readability, I suggest that the three registrations packed into Section 7.2.1 be separated somehow, as right now they appear to be one continuous bullet list.  Separate subsections would work, or even just a line of prose before each would suffice.

The first half of the second paragraph of Section 6 seems much more like an interoperability issue than a privacy issue to me.

[Ballot comment]
Thank you for the work put into this document.

Minor regret about the doc shepherd's write-up as it does not include anything about the WG consensus/discussion.

Cosmetic suggestion/nit in section 2.2: expanding 'iss', 'exp', ... could be useful for readers (even if I could guess 'issue' , 'expiration', ...)

Regards

-éric

[Ballot comment]
Section 2.1

  JWT access tokens MUST include this media type in the "typ" header
  parameter to explicitly declare that the JWT represents an access
  token complying with this profile.  Per the definition of "typ" in
  Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/"
  prefix be omitted.  [...]

Just to check: is the reason this is only RECOMMENDED just because
that's the requirement level that RFC 7515 used?  AFAIK we can be more
stringent here and just always require it to appear as "at+jwt", to
simplify processing, if that is compatible with existing deployments (or
we are willing to declare them non-conformant).  (Section 4 would change
accordingly if this text changes.)

Section 2.2

Why does "iat" get an extra sentence describing the claim in addition to
"as defined in [reference]" but not iss/exp/jti/etc.?

Section 2.2.1

  response (e.g., via the implicit flow) or after one or more token
  exchanges (e.g., obtaining a fresh access token using a refresh
  token, or exchanging one access token for another via [RFC8693]).

nit: RFC 8693 doesn't effectuate token exchange; the protocol it
specifies does.  So "via the token exchange mechanism of [RFC8693]" or
"via [RFC8693] procedures" or such seems more grammatically correct.

Section 2.2.2

  Any additional identity attribute whose semantic is well described by
  an entry in the JSON Web Token (JWT) IANA registry introduced in
  [RFC7519] SHOULD be encoded using the corresponding claim name.  Note
  that the JWT IANA registry includes the claims found in Section 5.1
  of [OpenID.Core].

I assume that ths "SHOULD be encoded using the corresponding claim name"
just refers to the claim name used, and is not advising that all
identity attributes be always included.  If so, perhaps a few more words
would help clarify, such as "if that attribute is to be included in the
JWT access token" at the end of the sentence.  Semantically it would
also work to start the sentence with "when being included", but IMO that
would detract from the focus of the sentence.

  Authorization servers including resource owner attributes in JWT
  access tokens should exercise care and verify that all privacy
  requirements are met, as discussed in Section 6.

I'd suggest to s/should/need to/.

Section 2.2.3

  All the individual scope strings in the "scope" claim MUST have
  meaning for the resources indicated in the "aud" claim.  See
  Section 5 for more considerations about the relationship between
  scope strings and resources indicated by the "aud" claim.

["aud" vs "resource?]

Section 2.2.3.1

  An authorization server wanting to include such attributes in a JWT
  access token SHOULD use as claim types the "groups","roles" and
  "entitlements" attributes of the "User" resource schema defined by
  Section 4.1.2 of [RFC7643]).

I do see that we go on to clarify that we register JWT claims for
"groups", "roles", and "entitlements" and recommend encoding guidance
for the values of these claims, but I'm still stumbling over the phrase
"claim types" here.  What is a "claim type"?  I suspect from context
that it is meant to refer to a "claim name" as recorded in the JWT
Claims registry, but I'm not 100% certain.  It might also help
readability to split this into two sentences: "use as claims [list].
The semantic contents of these claims are desribed in their definitions
as attributes of [...]", since the current wording has me trying to use
"attributes" in a JWT context, but it's intended to clarify the RFC 7643
reference.

  Authorization servers SHOULD encode the corresponding claim values
  according to the guidance defined in [RFC7643].  In particular, a

Why is this only a "SHOULD"?  We are defining these JWT claims, so we
can nail down exactly what they contain.

  non-normative example of "groups" attribute can be found in
  Section 8.2 of [RFC7643].  No specific vocabulary is provided for
  "roles" and "entitlements".

Similarly, we may want to be more concrete about "roles" and
"entitlements" if we don't already later in this document.

Section 3

This section is titled "Requesting a JWT Access Token" but the contents
don't really seem to provide a procedure for specifically requesting a
JWT access token.

(nit) the "exp" claim in the example is from 2018; we might want to use
something a little more "current" to time of actual publication.

Is the provided "state" in the example sufficiently long to provide CSRF
protection (as is recommended by RFC 6749)?

Section 4

  Authorization servers SHOULD use OAuth 2.0 Authorization Server
  Metadata [RFC8414] to advertise to resource servers their signing
  keys via "jwks_uri" and what "iss" claim value to expect via the
  issuer metadata value.  Alternatively, authorization servers

(nit) please use consistent formatting and terminology for the
"jwks_uri" and "issuer" metadata values.

  o  If the JWT access token is encrypted, decrypt it using the keys
      and algorithms that the resource server specified during
      registration.  If encryption was negotiated with the authorization
      server at registration time and the incoming JWT access token is
      not encrypted, the resource server SHOULD reject it.

Why is this only a SHOULD and not a MUST?

  o  The resource server MUST validate the signature of all incoming
      JWT access tokens according to [RFC7515] using the algorithm
      specified in the JWT alg Header Parameter.  The resource server
      MUST reject any JWT in which the value of "alg" is "none".  The
      resource server MUST use the keys provided by the authorization
      server.

Would the algorithm verification of Sections 3.1 and 3.2 of RFC 8725 be
relevant here?  Also, might local policy decide in the future to blanket
reject (then-)weak algorithms that are not "none"?

  o  The current time MUST be before the time represented by the "exp"
      claim.

RFC 7519 talk about an optional small leeway, "usually no more than a
few minutes" to account for clock skew; are we taking a stance one way
or the other on such leeway?

  The resource server MUST handle errors as described in Section 3.1 of
  [RFC6750].  [...]

I'm not sure that I saw anything before now in this document that
limits its applicability to bearer tokens only.  Do we need to start
now?

Section 5

  Authorization servers should prevent scenarios where clients can
  affect the value of the "sub" claim in ways that could confuse
  resource servers.  For example, if the authorization server elects to
  use the client_id as the "sub" value for access tokens issued client
  credentials grant, the authorization server should prevent clients to

nit: missing word (maybe "using the client credentials grant"?)

  register an arbitrary client_id value, as this would allow malicious

nit: s/to register/from registering/

  To preventing cross-JWT confusion, authorization servers MUST use a

nit: s/preventing/prevent/

  Authorization servers should use particular care when handling
  requests that might lead to ambiguous authorization grants.  For
  example: if a request includes multiple resource indicators, the
  authorization server should ensure that each scope string included in
  the resulting JWT access token, if any, can be unambiguously
  correlated to a specific resource among the ones listed in the "aud"
  claim.  The details on how to recognize and mitigate this and other
  ambiguous situations is highly scenario-dependent, hence out of scope
  for this profile.

Only using single-valued "aud" would also help prevent this kind of
mix-up, right?  Do we have a recommendation for single-valued "aud" in
one of the BCPs that we could point to?

  Authorization servers should not rely on the use of different keys
  for signing OpenID Connect ID Tokens and JWT tokens as a method to

nit: maybe s/should not/cannot/, since this is just a statement of fact?

Section 6

  As JWT access tokens carry information by value, it now becomes
  possible for clients and potentially even end users to directly peek
  inside the token claims collection.

(nit?) "of unencrypted tokens"?

  token is visible to the client.  Whenever client access to the access
  token content presents privacy issues for a given scenario, the
  authorization server should take explicit steps to prevent it.

I suggest s/should/needs to/.

  In every scenario, the content of the JWT access token will
  eventually be accessible to the resource server.  It's important to
  evaluate whether the resource server gained the proper entitlement to
  have access to any content received in form of claims, for example
  through user consent in some form, policies and agreements with the
  organization running the authorization servers, and so on.

I feel like it might be helpful to call out here that claims like those
including information about RO authentication (Section 2.2.1), identity
claims (Section 2.2.2), and authorization claims (Section 2.2.3) are
ones that not all RSes should be entitled to access.  I'm not sure about
the best way to indicate this, but perhaps another sentence at the end
about "For example, a user might not wish to consent to granting a given
RS information about any of the non-mandatory claims enumerated in
Section 2.2 (and subsections)" would help.

Section 8.1

URLs for the OIDC documents would be helpful.

I think RFC 7523 does not need to be normative.

Section 8.2

Please include the draft name for [OAuth2.Security.BestPractices] (I
assume it's draft-ietf-oauth-security-topics).

We have a "MUST handle errors as described in Section 3.1 of [RFC6750]"
which would make RFC 6750 a normative reference (but one of my comments
suggests that we may not want to limit ourselves to just those
procedures).

[Ballot comment]
I've never used JWT, and have only made slight use of OAUTH, so, um, sure?

Thank for writing this - it was a good and easy read...

[Ballot comment]
Thank you for the work on this document. Please find some comments and clarifying questions below.

Francesca

1. -----

      registration.  If encryption was negotiated with the authorization
      server at registration time and the incoming JWT access token is
      not encrypted, the resource server SHOULD reject it.

FP: Why is this just SHOULD and not MUST? In which case does it make sense to accept a non-encrypted token when encryption was negotiated?

2. -----

Section 2.1:

  Section 4).  JWT access tokens MUST NOT use "none" as the signing
  algorithm.  See Section 4 for more details.

Section 4:

  For the purpose of facilitating validation data retrieval, it is here
  RECOMMENDED that authorization servers sign JWT access tokens with an
  asymmetric algorithm.

  ...

  o  The resource server MUST validate the signature of all incoming
      JWT access tokens according to [RFC7515] using the algorithm
      specified in the JWT alg Header Parameter.  The resource server


FP: It might be obvious, but I think it would be useful to have an explicit sentence stating that JWT MUST be signed. The quoted text from Section 2.1 seem to imply it. Section 4 only RECOMMENDS that the JWT is signed with and asymmetric algorithm. Later on, Section 4 implies that all JWT are signed. On the other hand I note that encryption can be negotiated (and is optional) from the followig point; in that case it is not clear that the token is still signed (so the nested JWT would be a JWE nested in a JWS), or only JWE is used. What I am looking for is simple clarifications to be added for example in the introduction.

    o  If the JWT access token is encrypted, decrypt it using the keys
      and algorithms that the resource server specified during
      registration.  If encryption was negotiated with the authorization

3. -----

On the same note, and depending on the previous answer, why is the media type registered and used "application/at+jwt" and not something like "application/at+jws"/"application/at+jwe" or rather "application/at+jose" to be compliant with https://www.rfc-editor.org/rfc/rfc7515.html#section-9.2.1 ? I think that the structure transported is in fact a JWS or a JWE, rather than the JWT, and if that's the case that should be made clear in the text (one example where this could be clarified is in the following sentence)

  Resource servers receiving a JWT access token MUST validate it in the
  following manner.

[Ballot comment]
(2.1) "...can use any signing algorithm." I presume there ought to be some qualifiers on allowed algorithms?

(4) and (5) "This specification
  does not provide a mechanism for identifying a specific key as the
  one used to sign JWT access tokens."

I don't understand; there's a key ID right there in the token header?

(4) I presume it's important that any resouree server rejection of the token should be constant-time. Is this somewhere in the RFC tree, or do we need to explicitly say it here and/or in Security Considerations?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-oauth-access-token-jwt-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

In the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new registration will be made as follows:

Name: at+jwt
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

three claims will be registered as follows:

Claim Name: roles
Claim Description: Roles
Change controller: IESG
Reference: [ RFC-to-be ]

Claim Name: groups
Claim Description: Groups
Change controller: IESG
Reference: [ RFC-to-be ]

Claim Name: entitlements
Claim Description: Entitlements
Change controller: IESG
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-09):

From: The IESG
To: IETF-Announce
CC: Hannes Tschofenig , draft-ietf-oauth-access-token-jwt@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a profile for issuing OAuth 2.0 access
  tokens in JSON web token (JWT) format.  Authorization servers and
  resource servers from different vendors can leverage this profile to
  issue and consume access tokens in interoperable manner.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-Up for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"


(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?

This specification is proposed as a 'Standards Track' document. The
type of RFC is indicated.

(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 a profile for issuing OAuth 2.0 access
  tokens in JSON web token (JWT) format.  Authorization servers and
  resource servers from different vendors can leverage this profile to
  issue and consume access tokens in interoperable manner.

Working Group Summary

  The OAuth working group has defined an encoding format for access
  tokens in RFC 7519. This document takes deployment practice and
  summarizes it in this document with regards to the content
  in the JWT access token.
 
Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


The JWT access token is widely used in industry.

Here is a list of implementations based on feedback on the mailing list:

Node.js project oidc-provider (https://github.com/panva/node-oidc-provider) has an
option to issue Access Tokens conforming to this profile.

IdentityServer implements this functionality:
https://github.com/IdentityServer

Connect2id server implements this specification:
https://connect2id.com/products/server/docs/datasheet#access-token-encoding-jwt

Glewlwyd's OIDC plugin implements an earlier version of the specification:
https://github.com/babelouest/glewlwyd/blob/master/docs/OIDC.md#access-token-format
https://github.com/babelouest/glewlwyd

The working group has received feedback from the deployment community
and there is consensus on the content of the document.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Roman Danyliw.

(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 document shepherd was involved in the working group review process.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews.

(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.

There are no other reviews needed.

(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 document shepherd has no concerns with the 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.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

Vittorio: https://mailarchive.ietf.org/arch/msg/oauth/c4YrjZXNs4-pg5TNARnwL4NjQrc/


(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 for this document.

(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? 

There is solid consensus in the working group for publishing 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.)

Denis Pinkas has raised concerns about the design decisions on the mailing list.
These concerns relate to the way how the OAuth 2.0 architecture handles access
tokens. In particular, Denis expressed discomfort that the OAuth client does
not take a more active role in requesting the use of this profile and the
ability to inspect the access token content.

(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 checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(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 no normative references that prevent advancement of this document.

(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.

There are no downward normative references. There is, however, a reference
to a non-IETF RFC, namely to

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C.
Mortimore, "OpenID Connect Core 1.0", November 2014.

(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.

This document does not change the status of an existing RFC.

(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).

This document requires a new media type to be registered and also adds
new claims to the JWT claims registry. The relevant registries are clearly
identified.

(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.

This document does not create 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 is no text in formal languages in the document.

Shepherd Write-Up for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"


(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?

This specification is proposed as a 'Standards Track' document. The
type of RFC is indicated.

(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 a profile for issuing OAuth 2.0 access
  tokens in JSON web token (JWT) format.  Authorization servers and
  resource servers from different vendors can leverage this profile to
  issue and consume access tokens in interoperable manner.

Working Group Summary

  The OAuth working group has defined an encoding format for access
  tokens in RFC 7519. This document takes deployment practice and
  summarizes it in this document with regards to the content
  in the JWT access token.
 
Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


The JWT access token is widely used in industry.

Here is a list of implementations based on feedback on the mailing list:

Node.js project oidc-provider (https://github.com/panva/node-oidc-provider) has an
option to issue Access Tokens conforming to this profile.

IdentityServer implements this functionality:
https://github.com/IdentityServer

Connect2id server implements this specification:
https://connect2id.com/products/server/docs/datasheet#access-token-encoding-jwt

Glewlwyd's OIDC plugin implements an earlier version of the specification:
https://github.com/babelouest/glewlwyd/blob/master/docs/OIDC.md#access-token-format
https://github.com/babelouest/glewlwyd

The working group has received feedback from the deployment community
and there is consensus on the content of the document.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Roman Danyliw.

(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 document shepherd was involved in the working group review process.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews.

(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.

There are no other reviews needed.

(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 document shepherd has no concerns with the 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.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

Vittorio: https://mailarchive.ietf.org/arch/msg/oauth/c4YrjZXNs4-pg5TNARnwL4NjQrc/


(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 for this document.

(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? 

There is solid consensus in the working group for publishing 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.)

Denis Pinkas has raised concerns about the design decisions on the mailing list.
These concerns relate to the way how the OAuth 2.0 architecture handles access
tokens. In particular, Denis expressed discomfort that the OAuth client does
not take a more active role in requesting the use of this profile and the
ability to inspect the access token content.

(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 checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(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 no normative references that prevent advancement of this document.

(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.

There are no downward normative references. There is, however, a reference
to a non-IETF RFC, namely to

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C.
Mortimore, "OpenID Connect Core 1.0", November 2014.

(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.

This document does not change the status of an existing RFC.

(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).

This document requires a new media type to be registered and also adds
new claims to the JWT claims registry. The relevant registries are clearly
identified.

(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.

This document does not create 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 is no text in formal languages in the document.