JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
draft-ietf-oauth-access-token-jwt-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-10-14
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-10-11
|
13 | (System) | RFC Editor state changed to AUTH48 |
2021-09-16
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-09-07
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-09-07
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-09-07
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-09-03
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-08-31
|
13 | (System) | RFC Editor state changed to EDIT |
2021-08-31
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-08-31
|
13 | (System) | Announcement was received by RFC Editor |
2021-08-31
|
13 | (System) | IANA Action state changed to In Progress |
2021-08-31
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-08-31
|
13 | Amy Vezza | IESG has approved the document |
2021-08-31
|
13 | Amy Vezza | Closed "Approve" ballot |
2021-08-31
|
13 | Amy Vezza | Ballot approval text was generated |
2021-08-31
|
13 | (System) | Removed all action holders (IESG state changed) |
2021-08-31
|
13 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Revised I-D Needed |
2021-07-09
|
13 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2021-05-25
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-25
|
13 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-13.txt |
2021-05-25
|
13 | (System) | New version approved |
2021-05-25
|
13 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2021-05-25
|
13 | Vittorio Bertocci | Uploaded new revision |
2021-04-08
|
12 | Joseph Salowey | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list. |
2021-04-08
|
12 | (System) | Changed action holders to Vittorio Bertocci (IESG state changed) |
2021-04-08
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-04-07
|
12 | Murray Kucherawy | [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 … [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. |
2021-04-07
|
12 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-04-07
|
12 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-04-07
|
12 | Éric Vyncke | [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 … [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 |
2021-04-07
|
12 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-04-06
|
12 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-04-06
|
12 | Benjamin Kaduk | [Ballot comment] Section 2.1 JWT access tokens MUST include this media type in the "typ" header parameter to explicitly declare that the JWT … [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). |
2021-04-06
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-04-06
|
12 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-04-06
|
12 | Warren Kumari | [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 … [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... |
2021-04-06
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-04-06
|
12 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-04-06
|
12 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-04-05
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-04-04
|
12 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Please find some comments and clarifying questions below. Francesca 1. ----- registration. … [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. |
2021-04-04
|
12 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-04-01
|
12 | Martin Duke | [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 … [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? |
2021-04-01
|
12 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-04-01
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2021-04-01
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2021-03-30
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-03-30
|
12 | Amanda Baber | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2021-03-30
|
12 | Amy Vezza | Placed on agenda for telechat - 2021-04-08 |
2021-03-30
|
12 | Roman Danyliw | Ballot has been issued |
2021-03-30
|
12 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2021-03-30
|
12 | Roman Danyliw | Created "Approve" ballot |
2021-03-30
|
12 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2021-03-30
|
12 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2021-03-30
|
12 | Roman Danyliw | Ballot writeup was changed |
2021-03-17
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-03-17
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2021-03-17
|
12 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-12.txt |
2021-03-17
|
12 | (System) | New version approved |
2021-03-17
|
12 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2021-03-17
|
12 | Vittorio Bertocci | Uploaded new revision |
2021-02-25
|
11 | Roman Danyliw | See IETF LC SECDIR Review: https://mailarchive.ietf.org/arch/msg/oauth/Nbd1Xtk8ILnDRn7bitUZZqcAy2s/ |
2021-02-25
|
11 | (System) | Changed action holders to Vittorio Bertocci (IESG state changed) |
2021-02-25
|
11 | Roman Danyliw | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2021-02-09
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-02-08
|
11 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2021-02-08
|
11 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-02-08
|
11 | Sabrina Tanamal | (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 … (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 |
2021-02-07
|
11 | Joseph Salowey | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. Sent review to list. |
2021-02-07
|
11 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
2021-02-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2021-02-04
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2021-01-28
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2021-01-28
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2021-01-28
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2021-01-28
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2021-01-26
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2021-01-26
|
11 | Amy Vezza | 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, … 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. |
2021-01-26
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2021-01-26
|
11 | Amy Vezza | Last call announcement was changed |
2021-01-25
|
11 | Roman Danyliw | Last call was requested |
2021-01-25
|
11 | Roman Danyliw | Last call announcement was generated |
2021-01-25
|
11 | Roman Danyliw | Ballot approval text was generated |
2021-01-25
|
11 | Roman Danyliw | Ballot writeup was generated |
2021-01-25
|
11 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-01-22
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-22
|
11 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-11.txt |
2021-01-22
|
11 | (System) | New version approved |
2021-01-22
|
11 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2021-01-22
|
11 | Vittorio Bertocci | Uploaded new revision |
2020-11-15
|
10 | Roman Danyliw | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2020-11-15
|
10 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/oauth/2X21bY6xJCvFXjL7_CnKjt-XyTM/ |
2020-10-08
|
10 | Hannes Tschofenig | 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 … 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. |
2020-10-08
|
10 | Hannes Tschofenig | Responsible AD changed to Roman Danyliw |
2020-10-08
|
10 | Hannes Tschofenig | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-10-08
|
10 | Hannes Tschofenig | IESG state changed to Publication Requested from I-D Exists |
2020-10-08
|
10 | Hannes Tschofenig | IESG process started in state Publication Requested |
2020-10-08
|
10 | Hannes Tschofenig | Changed consensus to Yes from Unknown |
2020-10-08
|
10 | Hannes Tschofenig | Intended Status changed to Proposed Standard from None |
2020-10-08
|
10 | Hannes Tschofenig | 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 … 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. |
2020-09-23
|
10 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-10.txt |
2020-09-23
|
10 | (System) | New version approved |
2020-09-23
|
10 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-09-23
|
10 | Vittorio Bertocci | Uploaded new revision |
2020-09-18
|
09 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-09.txt |
2020-09-18
|
09 | (System) | New version approved |
2020-09-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-09-18
|
09 | Vittorio Bertocci | Uploaded new revision |
2020-09-14
|
08 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-08.txt |
2020-09-14
|
08 | (System) | New version approved |
2020-09-14
|
08 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-09-14
|
08 | Vittorio Bertocci | Uploaded new revision |
2020-05-26
|
07 | Rifaat Shekh-Yusef | Notification list changed to Hannes Tschofenig <hannes.tschofenig@arm.com> |
2020-05-26
|
07 | Rifaat Shekh-Yusef | Document shepherd changed to Hannes Tschofenig |
2020-05-13
|
07 | Rifaat Shekh-Yusef | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-04-27
|
07 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-07.txt |
2020-04-27
|
07 | (System) | New version approved |
2020-04-27
|
07 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-04-27
|
07 | Vittorio Bertocci | Uploaded new revision |
2020-04-15
|
06 | Rifaat Shekh-Yusef | IETF WG state changed to In WG Last Call from WG Document |
2020-04-15
|
06 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-06.txt |
2020-04-15
|
06 | (System) | New version approved |
2020-04-15
|
06 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-04-15
|
06 | Vittorio Bertocci | Uploaded new revision |
2020-03-31
|
05 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-05.txt |
2020-03-31
|
05 | (System) | New version approved |
2020-03-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-03-31
|
05 | Vittorio Bertocci | Uploaded new revision |
2020-03-06
|
04 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-04.txt |
2020-03-06
|
04 | (System) | New version approved |
2020-03-06
|
04 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2020-03-06
|
04 | Vittorio Bertocci | Uploaded new revision |
2019-12-16
|
03 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-03.txt |
2019-12-16
|
03 | (System) | New version approved |
2019-12-16
|
03 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2019-12-16
|
03 | Vittorio Bertocci | Uploaded new revision |
2019-07-24
|
02 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-02.txt |
2019-07-24
|
02 | (System) | New version approved |
2019-07-24
|
02 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2019-07-24
|
02 | Vittorio Bertocci | Uploaded new revision |
2019-07-21
|
01 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-01.txt |
2019-07-21
|
01 | (System) | New version approved |
2019-07-21
|
01 | (System) | Request for posting confirmation emailed to previous authors: Vittorio Bertocci |
2019-07-21
|
01 | Vittorio Bertocci | Uploaded new revision |
2019-04-22
|
00 | Rifaat Shekh-Yusef | This document now replaces draft-bertocci-oauth-access-token-jwt instead of None |
2019-04-22
|
00 | Vittorio Bertocci | New version available: draft-ietf-oauth-access-token-jwt-00.txt |
2019-04-22
|
00 | (System) | WG -00 approved |
2019-04-22
|
00 | Vittorio Bertocci | Set submitter to "Vittorio Bertocci ", replaces to draft-bertocci-oauth-access-token-jwt and sent approval email to group chairs: oauth-chairs@ietf.org |
2019-04-22
|
00 | Vittorio Bertocci | Uploaded new revision |