The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
draft-ietf-oauth-jwsreq-34
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-08-10
|
34 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-08-03
|
34 | (System) | RFC Editor state changed to AUTH48 |
2021-06-01
|
34 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-05-13
|
34 | (System) | RFC Editor state changed to EDIT |
2021-04-21
|
34 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-04-21
|
34 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-04-21
|
34 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-04-21
|
34 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-04-16
|
34 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-04-15
|
34 | (System) | RFC Editor state changed to EDIT from IESG |
2021-04-15
|
34 | (System) | IANA Action state changed to In Progress from On Hold |
2021-04-15
|
34 | (System) | Removed all action holders (IESG state changed) |
2021-04-15
|
34 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-04-15
|
34 | Cindy Morgan | IESG has approved the document |
2021-04-15
|
34 | Cindy Morgan | Closed "Approve" ballot |
2021-04-15
|
34 | Cindy Morgan | Ballot approval text was generated |
2021-04-09
|
34 | Francesca Palombini | [Ballot comment] EDIT (09-04-2021) Thank you for addressing all my comments in v-34. Francesca =============== Original ballot - 07-04-2021 Thank you for the work on … [Ballot comment] EDIT (09-04-2021) Thank you for addressing all my comments in v-34. Francesca =============== Original ballot - 07-04-2021 Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS. Francesca 1. ----- A Request Object (Section 2.1) has the "mime-type" "application/ FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838 2. ----- The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes the extension FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4. 3. ----- If decryption fails, the Authorization Server MUST return an "invalid_request_object" error. ... If signature validation fails, the Authorization Server MUST return an "invalid_request_object" error. ... If the validation fails, then the Authorization Server MUST return an error as specified in OAuth 2.0 [RFC6749]. FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise. Also regarding the reference to RFC 6749 - can you add a specific section to reference? 4. ----- specified in the "alg" Header Parameter. If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be ... same parameter is provided in the query parameter. The Client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The Authorization Server then FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not? 5. ----- location, (b) check the content type of the response is "application/ FP: For consistency, please change "content type" to "media type". |
2021-04-09
|
34 | Francesca Palombini | Ballot comment text updated for Francesca Palombini |
2021-04-08
|
34 | Michael Jones | New version available: draft-ietf-oauth-jwsreq-34.txt |
2021-04-08
|
34 | (System) | New version approved |
2021-04-08
|
34 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Michael Jones , Nat Sakimura |
2021-04-08
|
34 | Michael Jones | Uploaded new revision |
2021-04-08
|
33 | (System) | Changed action holders to Nat Sakimura, Michael Jones, John Bradley (IESG state changed) |
2021-04-08
|
33 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-04-08
|
33 | Michelle Cotton | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-04-08
|
33 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-04-08
|
33 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-04-07
|
33 | Murray Kucherawy | [Ballot comment] Ah, jwsreq. We meet again. Fortunately, looking only at the diff from my last ballot comments to this one, I only have a … [Ballot comment] Ah, jwsreq. We meet again. Fortunately, looking only at the diff from my last ballot comments to this one, I only have a couple of minor things this time: Sections 9.2 and 9.3 each say they are registering "values", but each registers only one. "+1" to Francesca's points #1 and #5. Thanks for changing the media type name to use hyphens instead of dots. That avoided a big mess. |
2021-04-07
|
33 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-04-07
|
33 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-04-07
|
33 | Michael Jones | New version available: draft-ietf-oauth-jwsreq-33.txt |
2021-04-07
|
33 | (System) | New version approved |
2021-04-07
|
33 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Michael Jones , Nat Sakimura |
2021-04-07
|
33 | Michael Jones | Uploaded new revision |
2021-04-07
|
32 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-04-07
|
32 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-04-07
|
32 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure … [Ballot comment] Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS. Francesca 1. ----- A Request Object (Section 2.1) has the "mime-type" "application/ FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838 2. ----- The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes the extension FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4. 3. ----- If decryption fails, the Authorization Server MUST return an "invalid_request_object" error. ... If signature validation fails, the Authorization Server MUST return an "invalid_request_object" error. ... If the validation fails, then the Authorization Server MUST return an error as specified in OAuth 2.0 [RFC6749]. FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise. Also regarding the reference to RFC 6749 - can you add a specific section to reference? 4. ----- specified in the "alg" Header Parameter. If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be ... same parameter is provided in the query parameter. The Client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The Authorization Server then FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not? 5. ----- location, (b) check the content type of the response is "application/ FP: For consistency, please change "content type" to "media type". |
2021-04-07
|
32 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-04-06
|
32 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-04-06
|
32 | Martin Duke | [Ballot comment] After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just … [Ballot comment] After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just an editorial fix. If the server advertises that a signed object is required, then it cannot communicate with a client that does not support the extension. But if the object_required metadata is missing, then what is the metadata that tells the client to use a signed object if it can? IIUC the answer is that the server metadata includes the request_object_signing_alg_values_supported and/or request_object_encryption_alg_values_supported parameter in the metadata. It might be helpful to spell that out here. Is this correct? |
2021-04-06
|
32 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-04-06
|
32 | Benjamin Kaduk | [Ballot comment] Thank you for the new security considerations text in Sections 10.7 and 10.8 since I last reviewed; it does a great job capturing … [Ballot comment] Thank you for the new security considerations text in Sections 10.7 and 10.8 since I last reviewed; it does a great job capturing my comments (and the current deployed reality). Thanks also to Watson Ladd for the latest secdir review and the authors for their responses to it. Section 6.2 The Authorization Server MUST validate the signature of the JSON Web Signature [RFC7515] signed Request Object. The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. [...] The last version I reviewed had some language tying the algorithm used for verification back to a registration (and I commented that perhaps a registration might not always exist). This language seems to set the recipient up to blindly use the "alg" header parameter, even if it's "none", and we should probably have some hedging language here (I see we do have language elsewhere that bans "none" specifically)... If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. ... and maybe that would just take the form of swapping the order of these two sentences, now that I keep reading. Section 10.2 Do any of the procedures listed for steps (c) and/or (d) need to be performed in step (e) as well? (In particular, the requirements on the returned URI seem like they would still apply, and possibly the need for client authentication. Section 10.3 Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my previous review suggested that there might be value in future work that specifies the linkage across these endpoints to try to address the cross-phase attacks discussed in [FETT]. However, the paragraph that I had commented on (that mentions "an extension specification") has since been removed, and I failed to track down why just from a quick mailarchive search. There may well have been a good reason for removing it (and the reference to [FETT]), so please help refresh my memory if that's the case. Section 10.4 The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of RFC3986 [RFC3986] for more information regarding risks associated with URIs. My previous comments had mentioned that because of time skew the dereferenced request URI might actually have the contents of a different request than the one intended, and Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ pointed out that OIDC actually does use a nonce that would prevent such an occurrence. Hopefully Nat did get a chance to think about whether there was anything else that we should mention in this document, on this topic. ("There isn't anything else to mention here" is a fine answer; I just wanted to close the loop on that thread, since I didn't find one in the mail archive.) Section 11.1 nit: s/TFP/trusted third-party service/ (multiple instances), since we stopped using "Trust Framework Provider" in the main body. Sction 14.1 Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 -- thank you for referencing it as BCP 195! I expect the RFC Editor will catch the new reference if you don't want to figure out how to notate it properly. |
2021-04-06
|
32 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-04-06
|
32 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-04-06
|
32 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-04-06
|
32 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly … [Ballot comment] Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly the diff). Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- Is it normal that the abstract has a) and b) while the introduction has a), b), and c) ? -- Section 5.2 -- I see that "Many phones in the market as of this writing" is still in the text... Does this assertion still hold in 2021 ? Is it backed by some references ? |
2021-04-06
|
32 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-04-06
|
32 | Lars Eggert | [Ballot comment] Section 5.2, paragraph 5, comment: > The entire Request URI MUST NOT exceed 512 ASCII characters. There > are three reasons … [Ballot comment] Section 5.2, paragraph 5, comment: > The entire Request URI MUST NOT exceed 512 ASCII characters. There > are three reasons for this restriction. > > 1. Many phones in the market as of this writing still do not accept > large payloads. The restriction is typically either 512 or 1024 > ASCII characters. > > 2. On a slow connection such as 2G mobile connection, a large URL > would cause the slow response and therefore the use of such is > not advisable from the user experience point of view. What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to transmit; it's not clear that larger payloads would therefore be so much worse, given that the 2G latencies are probably the overriding issue here. Would a SHOULD NOT suffice? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4, paragraph 10, nit: - Signing it with the "RS256" algorithm results in this Request Object + Signing it with the "RS256" algorithm [RFC7518] results in this Request Object + ++++++++++ |
2021-04-06
|
32 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-03-31
|
32 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-32.txt |
2021-03-31
|
32 | (System) | New version approved |
2021-03-31
|
32 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Michael Jones , Nat Sakimura |
2021-03-31
|
32 | Nat Sakimura | Uploaded new revision |
2021-03-30
|
31 | Amy Vezza | Telechat date has been changed to 2021-04-08 from 2020-08-13 |
2021-03-30
|
31 | Roman Danyliw | Ballot has been issued |
2021-03-30
|
31 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2021-03-30
|
31 | Roman Danyliw | Created "Approve" ballot |
2021-03-30
|
31 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
2021-03-30
|
31 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2021-03-30
|
31 | Roman Danyliw | Ballot writeup was changed |
2021-03-18
|
31 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-03-18
|
31 | Michael Jones | New version available: draft-ietf-oauth-jwsreq-31.txt |
2021-03-18
|
31 | (System) | New version approved |
2021-03-18
|
31 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Michael Jones , Nat Sakimura |
2021-03-18
|
31 | Michael Jones | Uploaded new revision |
2021-02-24
|
30 | Roman Danyliw | See https://mailarchive.ietf.org/arch/msg/oauth/oEFC4rwdmcEtxu5tH48RYd_U5SI/ |
2021-02-24
|
30 | (System) | Changed action holders to Nat Sakimura, Michael Jones, John Bradley (IESG state changed) |
2021-02-24
|
30 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-01-19
|
30 | Roman Danyliw | See https://mailarchive.ietf.org/arch/msg/oauth/oEFC4rwdmcEtxu5tH48RYd_U5SI/ |
2021-01-19
|
30 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-01-13
|
30 | Roman Danyliw | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2020-10-20
|
30 | Amanda Baber | All OAuth registrations have been approved. |
2020-10-20
|
30 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-10-20
|
30 | Hannes Tschofenig | Shepherd Write-Up for "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet … Shepherd Write-Up for "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (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. It changes the encoding of the authorization request message. (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 The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. Working Group Summary The document changes the encoding of the parameters in the authorization request to a JSON-based encoding. 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 request object and the request uri is an optional feature in the OpenID Connect Core specification and two working groups in the OpenID Foundation (namely the Modrna WG and the FAPI WG) are considering using this extension. The following implementations are availble. As part of the OpenID Foundation certification program the following implementations of OpenID Connect Core indicate support for this functionality: * CZ.NIC mojeID, * Thierry Habart's SimpleIdentitySever v.2.0.0, * Roland Hedberg's pyoidc 0.7.7, * Peercraft ApS's Peercarft, * MIT's MITREidConnect, * Gluue Server 2.3, * Filip Skokan's node-oidc pre supports. Authlete (https://www.authlete.com/), a commerical, closed source server implementation, has also implemented this specification and is offering it. There is an open source implementation from NRI in PHP and Scala. NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc IdentityServer implements JAR: https://github.com/IdentityServer 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 and verified the document for correctness. (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. The document has been two IETF LCs. (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 specific 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: Nat: https://mailarchive.ietf.org/arch/msg/oauth/XvUwsdygsuOB7xY5-ah-VXkQUuY/ John: https://mailarchive.ietf.org/arch/msg/oauth/IYsgKLiBJxtMK3KKTkoKLlxm7WM/ Mike: https://mailarchive.ietf.org/arch/msg/oauth/35QQzS4Mdf_HyU4rRhAoLcGh800/ (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.) Nobody threatened an appeal or expressed extreme discontent. (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? All normative references are published RFCs. (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 references. (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 adds several entries to the OAuth Parameters IANA registry. The entries have been verified by the shepherds in their roles as experts for those registries. The document also registers a media type, namely "application/oauth-authz-req+jwt". This request has been reviewed already. The document adds values to two more registries, namely to - the "OAuth Dynamic Client Registration Metadata" registry, and - the "OAuth Authorization Server Metadata" registry. The 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. There are no new registries created by this specification. (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. The document contains JSON examples and those have been verified by the shepherd. |
2020-10-02
|
30 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-10-01
|
30 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-oauth-jwsreq-30. 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-jwsreq-30. If any part of this review is inaccurate, please let us know. We understand that when the IESG approves this document for publication, IANA will have two actions to complete. (Please note that because we do not yet have confirmation from the expert for Section 9.1, OAuth Parameters, that version 30 is approved, we are marking this document "IANA Not OK," even though the assignments have already been made.) First, IANA will update the references for the following existing registrations at https://www.iana.org/assignments/oauth-parameters to point to the current version of this document. In OAuth Parameters: iss authorization request IETF [RFC7519, Section 4.1.1][RFC-ietf-oauth-jwsreq-30] sub authorization request IETF [RFC7519, Section 4.1.2][RFC-ietf-oauth-jwsreq-30] aud authorization request IETF [RFC7519, Section 4.1.3][RFC-ietf-oauth-jwsreq-30] exp authorization request IETF [RFC7519, Section 4.1.4][RFC-ietf-oauth-jwsreq-30] nbf authorization request IETF [RFC7519, Section 4.1.5][RFC-ietf-oauth-jwsreq-30] iat authorization request IETF [RFC7519, Section 4.1.6][RFC-ietf-oauth-jwsreq-30] jti authorization request IETF [RFC7519, Section 4.1.7][RFC-ietf-oauth-jwsreq-30] In OAuth Authorization Server Metadata: require_signed_request_object Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". IETF [RFC-ietf-oauth-jwsreq-30, Section 10.5] In OAuth Dynamic Client Registration Metadata: require_signed_request_object Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". IETF [RFC-ietf-oauth-jwsreq-30, Section 10.5] Second, IANA will add the following entry to the media type registry at https://www.iana.org/assignments/media-types: application/oauth-authz-req+jwt [RFC-ietf-oauth-jwsreq-30] Thank you, Amanda Baber Lead IANA Services Specialist |
2020-09-25
|
30 | Watson Ladd | Request for Last Call review by SECDIR Completed: Serious Issues. Reviewer: Watson Ladd. Sent review to list. |
2020-09-24
|
30 | Joel Halpern | Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2020-09-24
|
30 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2020-09-24
|
30 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2020-09-24
|
30 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2020-09-24
|
30 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2020-09-22
|
30 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-09-18
|
30 | Roman Danyliw | Requested Last Call review by I18NDIR |
2020-09-18
|
30 | Roman Danyliw | Requested Last Call review by OPSDIR |
2020-09-18
|
30 | Roman Danyliw | Requested Last Call review by GENART |
2020-09-18
|
30 | Roman Danyliw | Requested Last Call review by SECDIR |
2020-09-18
|
30 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-10-02): From: The IESG To: IETF-Announce CC: rdd@cert.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org … The following Last Call announcement was sent out (ends 2020-10-02): From: The IESG To: IETF-Announce CC: rdd@cert.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' as Proposed Standard This document is being brought back for a second IETF Last Call to confirm consensus on changes made in response to multiple IESG Reviews in 2017 and 2019. 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 2020-10-02. 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 The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ No IPR declarations have been submitted directly on this I-D. |
2020-09-18
|
30 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-09-18
|
30 | Roman Danyliw | Last call was requested |
2020-09-18
|
30 | Roman Danyliw | IESG state changed to Last Call Requested from RFC Ed Queue |
2020-09-18
|
30 | Amy Vezza | Last call announcement was changed |
2020-09-18
|
30 | Amy Vezza | Last call announcement was generated |
2020-09-11
|
30 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2020-09-10
|
30 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-30.txt |
2020-09-10
|
30 | (System) | New version approved |
2020-09-10
|
30 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Michael Jones , Nat Sakimura |
2020-09-10
|
30 | Nat Sakimura | Uploaded new revision |
2020-09-10
|
29 | (System) | RFC Editor state changed to IESG from RFC-EDITOR |
2020-09-09
|
29 | (System) | IANA Action state changed to On Hold from Waiting on Authors |
2020-09-09
|
29 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-29.txt |
2020-09-09
|
29 | (System) | New version approved |
2020-09-09
|
29 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , Michael Jones , John Bradley |
2020-09-09
|
29 | Nat Sakimura | Uploaded new revision |
2020-09-08
|
28 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-09-08
|
28 | (System) | IANA Action state changed to In Progress from On Hold |
2020-09-06
|
28 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-08-21
|
28 | (System) | RFC Editor state changed to EDIT |
2020-08-21
|
28 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-08-21
|
28 | (System) | Announcement was received by RFC Editor |
2020-08-21
|
28 | (System) | IANA Action state changed to On Hold from In Progress |
2020-08-21
|
28 | (System) | IANA Action state changed to In Progress |
2020-08-21
|
28 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-08-21
|
28 | Amy Vezza | IESG has approved the document |
2020-08-21
|
28 | Amy Vezza | Closed "Approve" ballot |
2020-08-21
|
28 | Amy Vezza | Ballot approval text was generated |
2020-08-21
|
28 | Amy Vezza | Ballot writeup was changed |
2020-08-21
|
28 | Amy Vezza | Ballot writeup was changed |
2020-08-20
|
28 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2020-08-20
|
28 | Michael Jones | New version available: draft-ietf-oauth-jwsreq-28.txt |
2020-08-20
|
28 | (System) | New version approved |
2020-08-20
|
28 | (System) | Request for posting confirmation emailed to previous authors: Michael Jones , Nat Sakimura , John Bradley |
2020-08-20
|
28 | Michael Jones | Uploaded new revision |
2020-08-19
|
27 | John Bradley | New version available: draft-ietf-oauth-jwsreq-27.txt |
2020-08-19
|
27 | (System) | New version approved |
2020-08-19
|
27 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , oauth-chairs@ietf.org, Nat Sakimura |
2020-08-19
|
27 | John Bradley | Uploaded new revision |
2020-08-13
|
26 | Benjamin Kaduk | [Ballot comment] [updating again to link to https://mailarchive.ietf.org/arch/msg/oauth/POfiIMFXpUQTl5nPvgb7YDcLkE0/ to note that my first update kind of missed the point.] [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ … [Ballot comment] [updating again to link to https://mailarchive.ietf.org/arch/msg/oauth/POfiIMFXpUQTl5nPvgb7YDcLkE0/ to note that my first update kind of missed the point.] [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear. |
2020-08-13
|
26 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-08-13
|
26 | Amanda Baber | 9.2 and 9.3 have been approved. Waiting for 9.1 expert. |
2020-08-13
|
26 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2020-08-12
|
26 | Amanda Baber | 9.2 has been approved. Waiting for 9.1 and 9.3 experts. |
2020-08-12
|
26 | Amanda Baber | IANA Experts State changed to Reviews assigned |
2020-08-12
|
26 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-08-12
|
26 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-08-12
|
26 | Robert Wilton | [Ballot comment] Hi, Only one minor comment: I liked the reference to max URL size for older versions of Internet Explorer, but wonder if that … [Ballot comment] Hi, Only one minor comment: I liked the reference to max URL size for older versions of Internet Explorer, but wonder if that is still really relevant in 2020? Or perhaps it could now be removed? Regards, Rob |
2020-08-12
|
26 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-08-12
|
26 | Murray Kucherawy | [Ballot comment] The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates … [Ballot comment] The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates again as matter of course. Abstract: "... the communication through the user agents are not ..." -- s/are/is/ Section 1 expressly cites two IANA URLs. I suggest simply naming the registry or sub-registry; the URLs might not be permanent. Or if you like the URL, do it as a reference, as you did with [IANA.MediaType]. The two bullets at the end of Section 1 toggle between "crypto" and "cryptography". I suggest picking one, preferably the latter (as did the rest of the document). In Section 3, should URI and URL include references to their defining RFCs? I realize a reader familiar with this space probably knows those terms, but they seem to be the only acronyms without a reference here. When would an implementer legitimately disregard the SHOULD in Section 4? As Benjamin Kaduk also expressed, I'm a little puzzled by this text in Section 5.2: "The "request_uri" value MUST be reachable by the Authorization Server." Is this part of the protocol? All of the subsections of Section 9 say: "This specification adds the following values to the "OAuth Parameters" registry established ..." but they all are actually modifying different sub-registries. I suggest naming the sub-registries explicitly. I realize the subsection titles have it right, but this line of repeated prose had me squinting a bit. |
2020-08-12
|
26 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record |
2020-08-11
|
26 | Murray Kucherawy | [Ballot comment] The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates … [Ballot comment] The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates again as matter of course. |
2020-08-11
|
26 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2020-08-11
|
26 | Benjamin Kaduk | [Ballot comment] [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used … [Ballot comment] [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear. |
2020-08-11
|
26 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-08-11
|
26 | Benjamin Kaduk | [Ballot comment] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the … [Ballot comment] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear. |
2020-08-11
|
26 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-08-05
|
26 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs. I hope that this helps to … [Ballot comment] Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Should the document shepherd's write-up be updated ? It is dated October 2016... about 4 years ago. -- Section 5.2 -- Based on the long history of this document, is the following statement "Many phones in the market as of this writing still" still valid ? -- Section 5.2.1 -- Suggest to give a hint about the use of tfp.example.org (TFP is expanded only in section 10.2). == NITS == Please check the ID-NITS at https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-26.txt |
2020-08-05
|
26 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-07-27
|
26 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-26.txt |
2020-07-27
|
26 | (System) | New version accepted (logged-in submitter: Nat Sakimura) |
2020-07-27
|
26 | Nat Sakimura | Uploaded new revision |
2020-07-14
|
25 | Roman Danyliw | IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup |
2020-07-14
|
25 | Cindy Morgan | Telechat date has been changed to 2020-08-13 from 2017-02-16 |
2020-07-01
|
25 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-25.txt |
2020-07-01
|
25 | (System) | New version approved |
2020-07-01
|
25 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Nat Sakimura |
2020-07-01
|
25 | Nat Sakimura | Uploaded new revision |
2020-07-01
|
24 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-24.txt |
2020-07-01
|
24 | (System) | New version approved |
2020-07-01
|
24 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Nat Sakimura |
2020-07-01
|
24 | Nat Sakimura | Uploaded new revision |
2020-05-11
|
23 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-23.txt |
2020-05-11
|
23 | (System) | New version approved |
2020-05-11
|
23 | (System) | Request for posting confirmation emailed to previous authors: John Bradley , Nat Sakimura |
2020-05-11
|
23 | Nat Sakimura | Uploaded new revision |
2020-05-09
|
22 | John Bradley | New version available: draft-ietf-oauth-jwsreq-22.txt |
2020-05-09
|
22 | (System) | New version approved |
2020-05-07
|
22 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2020-05-07
|
22 | John Bradley | Uploaded new revision |
2020-04-19
|
21 | John Bradley | New version available: draft-ietf-oauth-jwsreq-21.txt |
2020-04-19
|
21 | (System) | New version approved |
2020-04-19
|
21 | (System) | Request for posting confirmation emailed to previous authors: oauth-chairs@ietf.org, Nat Sakimura , John Bradley |
2020-04-19
|
21 | John Bradley | Uploaded new revision |
2019-10-21
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-10-21
|
20 | John Bradley | New version available: draft-ietf-oauth-jwsreq-20.txt |
2019-10-21
|
20 | (System) | New version approved |
2019-10-21
|
20 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2019-10-21
|
20 | John Bradley | Uploaded new revision |
2019-07-15
|
19 | Roman Danyliw | This draft was mistakenly advanced to "approved-announcement to be sent". Moving it back to "IESG Evaluation" as this draft does not have sufficient IESG ballots. |
2019-07-15
|
19 | Roman Danyliw | IESG state changed to IESG Evaluation::AD Followup from Approved-announcement to be sent |
2019-07-03
|
19 | Benjamin Kaduk | [Ballot discuss] My apologies; my previous position was incomplete. Updated to note namespacing issues, and one minor terminology nit about "DNS-ID". There seem to be … [Ballot discuss] My apologies; my previous position was incomplete. Updated to note namespacing issues, and one minor terminology nit about "DNS-ID". There seem to be some pretty serious namespacing issues that are not discussed at all in this document. Specifically, using JWT as a container for OAuth 2.0 authorization request parameters (including extension parameters) introduces the usage of many new names (of JSON name/value pairs) into the JWT claims namespace. Furthermore, the addition is not bounded, as any new OAuth extension parameters are implicitly permitted to be used as well! The IANA Considerations make no mention of the collapsed namespace for JWT claims and OAuth 2.0 (authorization request) parameters, leaving substantial potential for collisions in the future. Relatedly, using "application/jwt" as the Content-type of the HTTP response from dereferencing the request_uri with no explicit indication of the type/profile of JWT used (whether in the content type or in the JWT claims themselves) gives some risk of misinterpretation of the content. Consider, for example, when that request_uri is dereferenced not by the authorization server in the process of fulfilling an authorization request, but instead by some other service that expects a different type of JWT. This second point is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? |
2019-07-03
|
19 | Benjamin Kaduk | [Ballot comment] Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality … [Ballot comment] Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When the client does not want to do the crypto. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. How can you "not want to do [the] crypto" but still be doing TLS (with crypto)? Perhaps we're looking for "not want to pay the additional overhead of JWS/JWE cryptography on top of TLS"? Section 1.1 RFC 8174 has updated BCP 14 boilerplate text to use. Section 3 nit: should this section be 2.3 to get wrapped into "terminology"? It might also be worth putting references in for the terms, though they are largely common knowledge at this point. Section 4 A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contains all the OAuth 2.0 [RFC6749] authorization request parameters including extension parameters. The parameters are represented as nit: "all the parameters" kind of sounds like "all that are defined". But I think the intent here is "any parameter used to process the request must come from the request object and URL query parameters are ignored", so maybe "MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request; parameters from other sources MUST NOT be used", akin to what we say down in Sections 5 and 6.3. But we need to be careful about the wording to not exclude the usage of the "request" and "request_uri" query parameters to find the Request Object! the JWT claims. Parameter names and string values MUST be included nit: maybe "the JWT claims of the object"? any extension parameters. This JSON [RFC7159] constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted. nit: I think we want "This JSON [RFC7159] object". (Long quote incoming) The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes extension variables such as "nonce" and "max_age". { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } Signing it with the "RS256" algorithm results in this Request Object value (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw Decoding the base64 of the body, we see: { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cbBjorklund Standards Track [Page 41] RFC 8343 YANG Interface Management March 2018 <enabled>true</enabled> </interface> </interfaces> </data> </rpc-reply> Appendix E. Example: NETCONF <get-data> Reply This section gives an example of a reply to the NETCONF <get-data> request for the operational state datastore for a device that implements the example data models above. This example uses the "origin" annotation, which is defined in the module "ietf-origin" [RFC8342]. <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"> <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:vlan="http://example.com/vlan" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> <interface or:origin="or:intended"> <name>eth0</name> <type>ianaift:ethernetCsmacd</type> <enabled>false</enabled> <admin-status>down</admin-status> <oper-status>down</oper-status> <if-index>2</if-index> <phys-address>00:01:02:03:04:05</phys-address> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <interface or:origin="or:intended"> <name>eth1</name> <type>ianaift:ethernetCsmacd</type> <enabled>true</enabled> <admin-status>up</admin-status> <oper-status>up</oper-status> Bjorklund Standards Track [Page 42] RFC 8343 YANG Interface Management March 2018 <if-index>7</if-index> <phys-address>00:01:02:03:04:06</phys-address> <higher-layer-if>eth1.10</higher-layer-if> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> <vlan:vlan-tagging>true</vlan:vlan-tagging> </interface> <interface or:origin="or:intended"> <name>eth1.10</name> <type>ianaift:l2vlan</type> <enabled>true</enabled> <admin-status>up</admin-status> <oper-status>up</oper-status> <if-index>9</if-index> <lower-layer-if>eth1</lower-layer-if> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> <vlan:base-interface>eth1</vlan:base-interface> <vlan:vlan-id>10</vlan:vlan-id> </interface> <!-- This interface is not configured --> <interface or:origin="or:system"> <name>eth2</name> <type>ianaift:ethernetCsmacd</type> <admin-status>down</admin-status> <oper-status>down</oper-status> <if-index>8</if-index> <phys-address>00:01:02:03:04:07</phys-address> <statistics> <discontinuity-time> 2013-04-01T03:00:00+00:00 </discontinuity-time> <!-- counters now shown here --> </statistics> </interface> <interface or:origin="or:intended"> <name>lo1</name> Bjorklund Standards Track [Page 43] RFC 8343 YANG Interface Management March 2018 <type>ianaift:softwareLoopback</type> <enabled>true</enabled> <admin-status>up</admin-status> <oper-status>up</oper-status> <if-index>1</if-index> ", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null }, "id_token": { "gender": null, "birthdate": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } I'm not sure where the "claims" claim is coming from -- 6749 doesn't seem to talk about it. (Note that this example is used later on as well.) Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED that it be removed after a reasonable timeout unless access control measures are taken. It sounds like a link to https://www.w3.org/TR/capability-urls/ might also be useful. Section 5.2.2 Do we want to remind the reader that the other query parameters are just for backwards compatibility? Section 5.2.3 The following is an example of this fetch process: GET /request.jwt HTTP/1.1 Host: tfp.example.org It's useful to show good hygeine in examples; can we get the extra entropy in this request that we have in the previous example(s)? Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. Does "the pre-registered algorithm" concept exist in the specs outside of draft-ietf-oauth-jwt-bcp? Section 8 HTTP clients MUST also verify the TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in It's probably easier to just say "using DNS-ID [RFC6125], to avoid man-in-the-middle attacks". Section 9 The error codes we list in Section 7 are already registered, for the OIDC usage. Do we want to say anything about that? (I guess it would be disallowed by process to try to update the existing registration to also point at this document.) Section 10 We probably also want to reference draft-ietf-oauth-jwt-bcp. Section 10.1 When sending the authorization request object through "request" parameter, it MUST either be signed using JWS [RFC7515] or encrypted using JWE [RFC7516] with then considered appropriate algorithm. Up in Section 5 we only allow (a) signed and (b) signed then encrypted; similarly, in Section 4 we reiterate "signed then encrypted". Why is it okay to talk about just "signed or encrypted" here? Section 10.2 (b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Similarly to the previous point, you also need to check the signature, which will always be there. (d) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. In this I don't think this is a complete sentence (and it's definitely not a parallel construction with (a)-(c)!). I think perhaps a crisp one-line summary of this method would be "Delegating the authorization check to a separate "Request Object to Request Object URI" endpoint on the Authorization Server". (The writing in the rest of this paragraph could also use an editing pass.) (e) A third party, such as a Trust Framework Provider, provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) above apply. In addition, the Authorization Server MUST know out-of-band that the Client utilizes the Trust Framework Operator. The Authorization Server also has to trust the third-party provider to actually do its job and not misbehave, right? Section 10.3 I'm not entirely sure what "[t]he endpoints ithat come into question in this specification" is supposed to mean -- is it just "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"? In [RFC6749], while Redirection URI is included, others are not included in the Authorization Request. As the result, the same applies to Authorization Request Object. nit: included in what? Section 10.4 It's probably also worth citing the generic URI security considerations from RFC 3986, here. Section 10.4.1 "request_uri", and (d) do not perform recursive GET on the "request_uri". nit: remove the "do" in order to make the construction parallel. Section 12.1 It is often hard for the user to find out if the personal data asked for is strictly necessary. A Trust Framework Provider can help the user by examining the Client request and comparing to the proposed processing by the Client and certifying the request. After the certification, the Client, when making an Authorization Request, can submit Authorization Request to the Trust Framework Provider to obtain the Request Object URI. side note: In my head the act of certification was the act of making the translation to a Request Object URI, so I'm kind of curious where my vision differs from reality. The third paragraph seems to mostly just be describing the procedure of how this flow works, which would not necessarily be specific to the privacy considerations section. Section 12.2.2 Even if the protected resource does not include a personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent per-user Request Object URI is used. A third party may observe it through browser nit: need an article for "persistent per-user Request Object URI" (or make it plural, as "URIs are used"). Therefore, per-user Request Object URI should be avoided. nit: I think this is better as "static per-user Requeste Object URIs". Section 13 Are there two different paragraphs for "contributions from the OAuth WG members"? Are they reflecting different types of contribution? |
2019-07-03
|
19 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-07-02
|
19 | Benjamin Kaduk | |
2019-07-02
|
19 | Benjamin Kaduk | [Ballot comment] Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality … [Ballot comment] Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When the client does not want to do the crypto. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. How can you "not want to do [the] crypto" but still be doing TLS (with crypto)? Perhaps we're looking for "not want to pay the additional overhead of JWS/JWE cryptography on top of TLS"? Section 1.1 RFC 8174 has updated BCP 14 boilerplate text to use. Section 3 nit: should this section be 2.3 to get wrapped into "terminology"? It might also be worth putting references in for the terms, though they are largely common knowledge at this point. Section 4 A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contains all the OAuth 2.0 [RFC6749] authorization request parameters including extension parameters. The parameters are represented as nit: "all the parameters" kind of sounds like "all that are defined". But I think the intent here is "any parameter used to process the request must come from the request object and URL query parameters are ignored", so maybe "MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request; parameters from other sources MUST NOT be used", akin to what we say down in Sections 5 and 6.3. But we need to be careful about the wording to not exclude the usage of the "request" and "request_uri" query parameters to find the Request Object! the JWT claims. Parameter names and string values MUST be included nit: maybe "the JWT claims of the object"? any extension parameters. This JSON [RFC7159] constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted. nit: I think we want "This JSON [RFC7159] object". (Long quote incoming) The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes extension variables such as "nonce" and "max_age". { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } Signing it with the "RS256" algorithm results in this Request Object value (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw Decoding the base64 of the body, we see: { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null }, "id_token": { "gender": null, "birthdate": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } I'm not sure where the "claims" claim is coming from -- 6749 doesn't seem to talk about it. (Note that this example is used later on as well.) Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED that it be removed after a reasonable timeout unless access control measures are taken. It sounds like a link to https://www.w3.org/TR/capability-urls/ might also be useful. Section 5.2.2 Do we want to remind the reader that the other query parameters are just for backwards compatibility? Section 5.2.3 The following is an example of this fetch process: GET /request.jwt HTTP/1.1 Host: tfp.example.org It's useful to show good hygeine in examples; can we get the extra entropy in this request that we have in the previous example(s)? Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. Does "the pre-registered algorithm" concept exist in the specs outside of draft-ietf-oauth-jwt-bcp? Section 9 The error codes we list in Section 7 are already registered, for the OIDC usage. Do we want to say anything about that? (I guess it would be disallowed by process to try to update the existing registration to also point at this document.) Section 10 We probably also want to reference draft-ietf-oauth-jwt-bcp. Section 10.1 When sending the authorization request object through "request" parameter, it MUST either be signed using JWS [RFC7515] or encrypted using JWE [RFC7516] with then considered appropriate algorithm. Up in Section 5 we only allow (a) signed and (b) signed then encrypted; similarly, in Section 4 we reiterate "signed then encrypted". Why is it okay to talk about just "signed or encrypted" here? Section 10.2 (b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Similarly to the previous point, you also need to check the signature, which will always be there. (d) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. In this I don't think this is a complete sentence (and it's definitely not a parallel construction with (a)-(c)!). I think perhaps a crisp one-line summary of this method would be "Delegating the authorization check to a separate "Request Object to Request Object URI" endpoint on the Authorization Server". (The writing in the rest of this paragraph could also use an editing pass.) (e) A third party, such as a Trust Framework Provider, provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) above apply. In addition, the Authorization Server MUST know out-of-band that the Client utilizes the Trust Framework Operator. The Authorization Server also has to trust the third-party provider to actually do its job and not misbehave, right? Section 10.3 I'm not entirely sure what "[t]he endpoints ithat come into question in this specification" is supposed to mean -- is it just "the OAuth 2.0 endpoints presently defined in Standards-Track RFCs"? In [RFC6749], while Redirection URI is included, others are not included in the Authorization Request. As the result, the same applies to Authorization Request Object. nit: included in what? Section 10.4 It's probably also worth citing the generic URI security considerations from RFC 3986, here. Section 10.4.1 "request_uri", and (d) do not perform recursive GET on the "request_uri". nit: remove the "do" in order to make the construction parallel. Section 12.1 It is often hard for the user to find out if the personal data asked for is strictly necessary. A Trust Framework Provider can help the user by examining the Client request and comparing to the proposed processing by the Client and certifying the request. After the certification, the Client, when making an Authorization Request, can submit Authorization Request to the Trust Framework Provider to obtain the Request Object URI. side note: In my head the act of certification was the act of making the translation to a Request Object URI, so I'm kind of curious where my vision differs from reality. The third paragraph seems to mostly just be describing the procedure of how this flow works, which would not necessarily be specific to the privacy considerations section. Section 12.2.2 Even if the protected resource does not include a personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent per-user Request Object URI is used. A third party may observe it through browser nit: need an article for "persistent per-user Request Object URI" (or make it plural, as "URIs are used"). Therefore, per-user Request Object URI should be avoided. nit: I think this is better as "static per-user Requeste Object URIs". Section 13 Are there two different paragraphs for "contributions from the OAuth WG members"? Are they reflecting different types of contribution? |
2019-07-02
|
19 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-06-10
|
19 | John Bradley | New version available: draft-ietf-oauth-jwsreq-19.txt |
2019-06-10
|
19 | (System) | New version approved |
2019-06-10
|
19 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2019-06-10
|
19 | John Bradley | Uploaded new revision |
2019-06-05
|
18 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-06-05
|
18 | Warren Kumari | [Ballot comment] "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is … [Ballot comment] "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term. I'm largely relying on the fact that the previous Ops&Mgmt AD's, Kathleen, Jari, Ben, et al balloted Yes or NoObj. |
2019-06-05
|
18 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-05-21
|
18 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-05-16
|
18 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2019-05-16
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-16
|
18 | John Bradley | New version available: draft-ietf-oauth-jwsreq-18.txt |
2019-05-16
|
18 | (System) | New version approved |
2019-05-16
|
18 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2019-05-16
|
18 | John Bradley | Uploaded new revision |
2019-05-02
|
17 | Roman Danyliw | New AD review per "Approved-announcement to be sent::Revised I-D Needed". See: https://mailarchive.ietf.org/arch/msg/oauth/nsg6Ork8r8tySLEW_hNeqBjClv8 |
2019-03-27
|
17 | Cindy Morgan | Shepherding AD changed to Roman Danyliw |
2018-12-21
|
17 | Eric Rescorla | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent |
2018-12-21
|
17 | Eric Rescorla | Still waiting on changes requested 11/20 |
2018-11-04
|
17 | Eric Rescorla | OK, I know what the problem is here. There aren't any YES responses, so I need to review this. I will do so. |
2018-10-21
|
17 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-17.txt |
2018-10-21
|
17 | (System) | New version approved |
2018-10-21
|
17 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2018-10-21
|
17 | Nat Sakimura | Uploaded new revision |
2018-06-28
|
16 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-04-06
|
16 | Eric Rescorla | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-04-05
|
16 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-16.txt |
2018-04-05
|
16 | (System) | New version approved |
2018-04-05
|
16 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2018-04-05
|
16 | Nat Sakimura | Uploaded new revision |
2017-07-21
|
15 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-15.txt |
2017-07-21
|
15 | (System) | New version approved |
2017-07-21
|
15 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2017-07-21
|
15 | Nat Sakimura | Uploaded new revision |
2017-07-21
|
15 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2017-07-21
|
15 | Nat Sakimura | Uploaded new revision |
2017-07-21
|
14 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS point. New nit: URN needs a reference to RFC 8141. |
2017-07-21
|
14 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2017-07-20
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-07-20
|
14 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-14.txt |
2017-07-20
|
14 | (System) | New version approved |
2017-07-20
|
14 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2017-07-20
|
14 | Nat Sakimura | Uploaded new revision |
2017-06-17
|
13 | Eric Rescorla | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2017-04-24
|
13 | Alexey Melnikov | [Ballot discuss] Thank you for addressing my DISCUSS about use of RFC 6125. I have one new small issue from your recent change in … [Ballot discuss] Thank you for addressing my DISCUSS about use of RFC 6125. I have one new small issue from your recent change in In 5.2.3 (that was addressing my comment to include a response example): the example doesn't include Content-Type and (possibly) Transfer-Encoding header fields. Without these it doesn't look syntactically correct. |
2017-04-24
|
13 | Alexey Melnikov | Ballot comment and discuss text updated for Alexey Melnikov |
2017-03-30
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-03-30
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-03-30
|
13 | John Bradley | New version available: draft-ietf-oauth-jwsreq-13.txt |
2017-03-30
|
13 | (System) | New version approved |
2017-03-30
|
13 | (System) | Request for posting confirmation emailed to previous authors: Nat Sakimura , John Bradley |
2017-03-30
|
13 | John Bradley | Uploaded new revision |
2017-03-29
|
12 | Amy Vezza | Shepherding AD changed to Eric Rescorla |
2017-02-16
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-02-16
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-02-16
|
12 | Alexey Melnikov | [Ballot discuss] When referencing RFC 6125 you need to provide more details. In particular, you need to pretty much answer every question in section 3 … [Ballot discuss] When referencing RFC 6125 you need to provide more details. In particular, you need to pretty much answer every question in section 3 of RFC 6125: One example of how this might look like is in Section 9.2 of . For your convenience the relevant text is pasted below: Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid man-in-the-middle attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". rpki-rtr implementations which use TLS MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [RFC6125]. The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.) |
2017-02-16
|
12 | Alexey Melnikov | Ballot discuss text updated for Alexey Melnikov |
2017-02-16
|
12 | Mirja Kühlewind | [Ballot comment] Should this document maybe update rfc6749? |
2017-02-16
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2017-02-16
|
12 | Mirja Kühlewind | [Ballot comment] Two minor questions: - Should this document maybe update rfc6749? - Should this be like this? OLD ""request" and "request_uri" parameters MUST … [Ballot comment] Two minor questions: - Should this document maybe update rfc6749? - Should this be like this? OLD ""request" and "request_uri" parameters MUST NOT be included in Request Objects." NEW ""request" and "request_uri" parameters MUST NOT be both included in Request Objects." |
2017-02-16
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-02-16
|
12 | Alexey Melnikov | [Ballot discuss] RFC 6125 use needs more details. <> |
2017-02-16
|
12 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record |
2017-02-16
|
12 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-02-16
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-02-15
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-02-15
|
12 | Ben Campbell | [Ballot comment] - 4, "Since it is a JWT, JSON strings MUST be represented in UTF-8. ": Is that a new requirement, or a … [Ballot comment] - 4, "Since it is a JWT, JSON strings MUST be represented in UTF-8. ": Is that a new requirement, or a statement of fact about an existing JWT requirement? - 5.2: I'm not sure all readers will understand the meaning of "feature phone". Also, WAP and 2G don't seem all that relevant in 2017. - 5.2.1, first sentence, "The URL MUST be HTTPS URL.": Is that redundant to the similar requirement in the previous section? That instance had an "unless" clause, but this one does not. --2nd paragraph: "... MUST have appropriate entropy for its lifetime." Can you offer discussion (or a reference) for what constitutes "appropriate entropy"? -- 3rd paragraph: Is it reasonable that one would know if TLS would offer adequate authentication at the time of the signing decision? - 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it ever be reasonable to not do this? - 6.1, 2nd paragraph: What if validation fails? - 13: Do you want this in the final RFC? If not, it would be wise to add a note to the RFC editor to that effect. |
2017-02-15
|
12 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2017-02-15
|
12 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-02-15
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-02-15
|
12 | Stephen Farrell | [Ballot comment] - intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find … [Ballot comment] - intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find details of some such attacks, so I hope you add some refs here. - section 3; WAP? Really? I'm surprised any WAP technology would still be in use, even on feature-phones. Do you really need this? - section 4: I think it will turn out to be an error to allow for mixing query parameters and protected parameters (in a Request Object) in a single request. Do you really need that level of flexibility? It'd be simpler and less likely to be attackable to insist that all parameters be in the Request Object if one is used. (See also section 11.2.1 below.) - section 10: Is there nothing to be said about the new indirection caused by the request_uri? I'd have thought there were some corner cases that'd warrant a mention, e.g. if some kind of deadlock or looping could happen, or if one client (in OAuth terms) could use a request_uri value as a way to attempt attacks (to be assisted by an innocent browser) against some resource owner. - section 11: thanks for that, it's good. - section 11: Saying that an ISO thing is "good to follow" is quite weak IMO. (And is that ISO spec accessible? Hmm... it seems that one needs to accept cookies to get it which is wonderfully ironic;-) If the authors have the energy, I'd suggest trying to find better guidance that's more publically available in a privacy-friendly manner. (Or just drop the ISO reference if 6973 is good enough.) |
2017-02-15
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-02-15
|
12 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-02-15
|
12 | Alexey Melnikov | [Ballot comment] In 5.2: a document defining HTTPS URI needs to be a normative reference. In 5.2.3: can you show an example of response (with … [Ballot comment] In 5.2: a document defining HTTPS URI needs to be a normative reference. In 5.2.3: can you show an example of response (with relevant HTTP Header Fields)? Or update example in 5.2 to include HTTP Header Fields. |
2017-02-15
|
12 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-02-14
|
12 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-02-14
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2017-02-14
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-02-14
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-02-14
|
12 | Kathleen Moriarty | Ballot has been issued |
2017-02-14
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2017-02-14
|
12 | Kathleen Moriarty | Created "Approve" ballot |
2017-02-14
|
12 | Kathleen Moriarty | Ballot writeup was changed |
2017-02-14
|
12 | Kathleen Moriarty | Ballot writeup was changed |
2017-02-14
|
12 | Kathleen Moriarty | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-02-13
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-02-13
|
12 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-12.txt |
2017-02-13
|
12 | (System) | New version approved |
2017-02-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2017-02-13
|
12 | Nat Sakimura | Uploaded new revision |
2017-02-13
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-02-09
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-02-09
|
11 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-oauth-jwsreq-11.txt, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-oauth-jwsreq-11.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-02-08
|
11 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Stephen Kent. |
2017-02-02
|
11 | Joel Halpern | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Joel Halpern. Sent review to list. |
2017-02-02
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2017-02-02
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2017-02-02
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2017-02-02
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2017-02-01
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Warren Kumari. |
2017-02-01
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Warren Kumari |
2017-02-01
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Warren Kumari |
2017-01-30
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-01-30
|
11 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: Kathleen.Moriarty.ietf@gmail.com, oauth@ietf.org, Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: Kathleen.Moriarty.ietf@gmail.com, oauth@ietf.org, Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' 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 ietf@ietf.org mailing lists by 2017-02-13. 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 The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream) rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream) Note that some of these references may already be listed in the acceptable Downref Registry. |
2017-01-30
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-01-30
|
11 | Kathleen Moriarty | Last call was requested |
2017-01-30
|
11 | Kathleen Moriarty | Ballot approval text was generated |
2017-01-30
|
11 | Kathleen Moriarty | Ballot writeup was generated |
2017-01-30
|
11 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD is watching |
2017-01-30
|
11 | Kathleen Moriarty | Last call announcement was generated |
2017-01-30
|
11 | Kathleen Moriarty | Placed on agenda for telechat - 2017-02-16 |
2017-01-30
|
11 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-11.txt |
2017-01-30
|
11 | (System) | New version approved |
2017-01-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2017-01-30
|
11 | Nat Sakimura | Uploaded new revision |
2017-01-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2017-01-30
|
11 | Nat Sakimura | Uploaded new revision |
2017-01-30
|
10 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-10.txt |
2017-01-30
|
10 | (System) | New version approved |
2017-01-30
|
10 | (System) | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2017-01-30
|
10 | Nat Sakimura | Uploaded new revision |
2017-01-25
|
09 | Warren Kumari | Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Warren Kumari. |
2017-01-25
|
09 | Kathleen Moriarty | Removed from agenda for telechat |
2017-01-24
|
09 | Joel Halpern | Request for Telechat review by GENART Completed: Not Ready. Reviewer: Joel Halpern. Sent review to list. |
2017-01-19
|
09 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. |
2017-01-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2017-01-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2017-01-12
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stephen Kent |
2017-01-12
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stephen Kent |
2017-01-10
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Warren Kumari |
2017-01-10
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Warren Kumari |
2017-01-06
|
09 | Kathleen Moriarty | Placed on agenda for telechat - 2017-02-02 |
2016-11-22
|
09 | Hannes Tschofenig | Added to session: IETF-97: oauth Mon-0930 |
2016-11-04
|
09 | Kathleen Moriarty | IESG state changed to AD is watching from AD Evaluation |
2016-10-28
|
09 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2016-10-10
|
09 | Hannes Tschofenig | Shepherd Write-Up for "OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, … Shepherd Write-Up for "OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" (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. It changes the encoding of the authorization request message. (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 The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authentciated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiallity property of the Authorization Request is attained. The request can be sent by value or by reference. Working Group Summary The document changes the encoding of the parameters in the authorization request to a JSON-based encoding. 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 request object and the request uri is an optional feature in the OpenID Connect Core specification and two working groups in the OpenID Foundation (namely the Modrna WG and the FAPI WG) are considering using this extension. As part of the OpenID Foundation certification program the following implementations of OpenID Connect Core indicate support for this functionality: * CZ.NIC mojeID, * Thierry Habart's SimpleIdentitySever v.2.0.0, * Roland Hedberg's pyoidc 0.7.7, * Peercraft ApS's Peercarft, * MIT's MITREidConnect, * Gluue Server 2.3, * Filip Skokan's node-oidc pre supports. Authlete (https://www.authlete.com/), a commerical, closed source server implementation, has also implemented this specification and is offering it. There is an open source implementation from NRI in PHP and Scala. NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Hannes Tschofenig is the document shepherd 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 document shepherd was involved in the working group review process and verified the document for correctness. (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 specific 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: Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg16675.html John: https://www.ietf.org/mail-archive/web/oauth/current/msg16701.html (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.) Nobody threatened an appeal or expressed extreme discontent. (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? All normative references are published RFCs. (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 two downrefs, namely * RFC 6234: US Secure Hash Algorithms * RFC 6819: OAuth Threat Model (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 does not request any actions by IANA. (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. None. (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. The document contains JSON examples and those have been verified by the shepherd. |
2016-10-10
|
09 | Hannes Tschofenig | Responsible AD changed to Kathleen Moriarty |
2016-10-10
|
09 | Hannes Tschofenig | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2016-10-10
|
09 | Hannes Tschofenig | IESG state changed to Publication Requested |
2016-10-10
|
09 | Hannes Tschofenig | IESG process started in state Publication Requested |
2016-10-10
|
09 | Hannes Tschofenig | Changed document writeup |
2016-10-10
|
09 | Hannes Tschofenig | Changed consensus to Yes from Unknown |
2016-10-10
|
09 | Hannes Tschofenig | Intended Status changed to Proposed Standard from None |
2016-09-27
|
09 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-09.txt |
2016-09-27
|
09 | Nat Sakimura | New version approved |
2016-09-27
|
09 | Nat Sakimura | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2016-09-27
|
09 | (System) | Uploaded new revision |
2016-09-27
|
08 | Nat Sakimura | Request for posting confirmation emailed to previous authors: "Nat Sakimura" , "John Bradley" |
2016-08-03
|
08 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-08.txt |
2016-01-19
|
07 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-07.txt |
2015-11-02
|
06 | Hannes Tschofenig | WGLC sent to the mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg15056.html |
2015-11-02
|
06 | Hannes Tschofenig | IETF WG state changed to In WG Last Call from WG Document |
2015-10-15
|
06 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-06.txt |
2015-07-22
|
05 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-05.txt |
2015-07-06
|
04 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-04.txt |
2015-07-06
|
03 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-03.txt |
2015-05-29
|
02 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-02.txt |
2014-11-12
|
01 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-01.txt |
2014-08-26
|
00 | Hannes Tschofenig | Document shepherd changed to Hannes Tschofenig |
2014-08-26
|
00 | Hannes Tschofenig | This document now replaces draft-sakimura-oauth-requrl instead of None |
2014-08-26
|
00 | Nat Sakimura | New version available: draft-ietf-oauth-jwsreq-00.txt |