Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
draft-ietf-oauth-proof-of-possession-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-04-04
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-03-14
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-02-23
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-01-12
|
11 | Pete Resnick | Assignment of request for Last Call review by GENART to Pete Resnick was rejected |
2016-01-12
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-01-12
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2016-01-12
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-01-07
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-12-28
|
11 | (System) | IANA Action state changed to In Progress |
2015-12-28
|
11 | (System) | RFC Editor state changed to EDIT |
2015-12-28
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-12-28
|
11 | (System) | Announcement was received by RFC Editor |
2015-12-28
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-12-28
|
11 | Amy Vezza | IESG has approved the document |
2015-12-28
|
11 | Amy Vezza | Closed "Approve" ballot |
2015-12-28
|
11 | Amy Vezza | Ballot approval text was generated |
2015-12-22
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed. Reviewer: Ron Bonica. |
2015-12-18
|
11 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-11.txt |
2015-12-17
|
10 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead |
2015-12-17
|
10 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-12-17
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-12-17
|
10 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-12-17
|
10 | Stephen Farrell | [Ballot comment] - Figure 1 and the discussion thereof: you talk all the time here about "a symmetric key" so I think you ought add … [Ballot comment] - Figure 1 and the discussion thereof: you talk all the time here about "a symmetric key" so I think you ought add a footnote like bit of text that says something like "note that there ought be more than one key involved here, derived from the key exchanged at (0) via a KDF." I kinda wish that all that had been covered in one document but I guess that's part of the PoP arch doc, which is for later. - 3.1 says "outside the scope of this specification": just wondering - does that phrase occur in all OAuth RFCs? (only kidding, honest:-) - section 4, para 2: replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration. - section 6: DE guidance - I think we ought tell the DEs that the specification of a new thing needs to explicitly describe the security properties of using the new thing. - I didn't see a response to the secdir review [1] but that was maybe sent to the wrong places. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06266.html |
2015-12-17
|
10 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-12-16
|
10 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-12-16
|
10 | Michael Jones | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-12-16
|
10 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-10.txt |
2015-12-16
|
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-12-16
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-12-16
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-12-16
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-12-16
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-12-15
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-12-15
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2015-12-15
|
09 | Barry Leiba | [Ballot comment] The Abstract and Introduction both say something like this: This specification defines how a JSON Web Token (JWT) [JWT] can declare … [Ballot comment] The Abstract and Introduction both say something like this: This specification defines how a JSON Web Token (JWT) [JWT] can declare that the presenter of the JWT possesses a key and that the recipient can cryptographically confirm that the presenter possesses that key. The JWT doesn't declare that the presenter possesses the key; it declares that the presenter *must* possess the key... yes? Shouldn't this say that?: NEW This specification defines how a JSON Web Token (JWT) [JWT] can declare that the presenter of the JWT must possess a key and how the recipient can cryptographically confirm that the presenter possesses that key. END (Also notice change from "that" to "how".) This specification defines how to communicate key confirmation key information in JWTs. "key confirmation key information" seems odd and hard to follow. I think "key information used in key confirmation" is a better way to say it. But perhaps the sentence as a whole could be better phrased. Does something like this work?: NEW This specification defines how to imbed into the JWT the key information that is used in key confirmation. END -- Section 2 -- Minor, very unimportant point: There's no reason to put, for example, "(JWT)", when the citation "[JWT]" immediately follows it. I suggest just using the citation to provide the abbreviation, and eliminating "(JWT)", "(JWK)", and "(JWE)". But very unimportant; do, or don't, and no need to respond to this item. -- Section 3 -- The issuer of a JWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof-of-possession of the key by the presenter by including a "cnf" (confirmation) claim in the JWT whose value is a JSON object. I was convinced that this wasn't right until I read it for about the eighth time. It sounds like the recipient includes the "cnf" claim in the JWT, when it's actually the issuer. That happens when long sentences have too many qualifiers strung together. How about this?: NEW By including a "cnf" (confirmation) claim in a JWT, the issuer of the JWT declares that the presenter possesses a particular key, and that the recipient can cryptographically confirm that the presenter has proof-of-possession of that key. The value in the cnf claim is a JSON object, and members in that object identify the proof-of-possession key. END -- Section 3.5 -- The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the JWK Set MUST use Transport Layer Security (TLS) [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Little editorial punctuational nonsense: I would make the first semicolon a colon instead (or perhaps a period), and I would then make the second semicolon a comma. -- Section 4 -- In the last paragraph, can you provide a reference for "audience restriction"? -- Section 6 -- Can we get this fixed in all the OAuth and JOSE documents? It's getting old having to make the same comment for every document: We should not be trying to set up IANA processes in our IANA Considerations. The fourth and sixth paragraphs aren't appropriate here: IANA coordinates and tracks registration requests, and all requests should go to IANA. IANA will contact the DEs, not the other way around. The authors have seen this comment from me before.... |
2015-12-15
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-12-14
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-12-14
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-12-14
|
09 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-oauth-proof-of-possession-08.txt. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-oauth-proof-of-possession-08.txt. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are two actions which IANA must complete. First, in the JSON Web Token Claims subregistry of the JSON Web Token (JWT) registry located at: http://www.iana.org/assignments/jwt/ a single new token claim will be registered as follows: Claim Name: cnf Claim Description: Confirmation Change Controller: IESG Reference: Section 3.1 of [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, a new registry will be created called the JWT Confirmation Methods registry. This registry is to be managed via Specification Required as defined in RFC 5226. IANA notes the registration requirements noted in Section 6 of [ RFC-to-be ]. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? The new registry has four initial registrations as follows: Confirmation Method Value: "jwk" Confirmation Method Description: JSON Web Key Representing Public Key Change Controller: IESG Specification Document(s): Section 3.2 of [ RFC-to-be ] Confirmation Method Value: "jwe" Confirmation Method Description: Encrypted JSON Web Key Change Controller: IESG Specification Document(s): Section 3.3 of [ RFC-to-be ] Confirmation Method Value: "kid" Confirmation Method Description: Key Identifier Change Controller: IESG Specification Document(s): Section 3.4 of [ RFC-to-be ] Confirmation Method Value: "jku" Confirmation Method Description: JWK Set URL Change Controller: IESG Specification Document(s): Section 3.5 of [ RFC-to-be ] IANA understands that the two actions above are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2015-12-13
|
09 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-09.txt |
2015-12-13
|
08 | Kathleen Moriarty | Ballot has been issued |
2015-12-13
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2015-12-13
|
08 | Kathleen Moriarty | Created "Approve" ballot |
2015-12-13
|
08 | Kathleen Moriarty | Ballot writeup was changed |
2015-12-13
|
08 | Kathleen Moriarty | Ballot writeup was changed |
2015-12-13
|
08 | Kathleen Moriarty | Changed consensus to Yes from Unknown |
2015-12-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2015-12-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2015-12-10
|
08 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Chris Lonvick. |
2015-12-03
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2015-12-03
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2015-12-02
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-12-02
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: Kathleen.Moriarty.ietf@gmail.com, oauth@ietf.org, kepeng.lkp@alibaba-inc.com, draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@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, kepeng.lkp@alibaba-inc.com, draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' 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 2015-12-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-12-02
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-12-02
|
08 | Kathleen Moriarty | Last call was requested |
2015-12-02
|
08 | Kathleen Moriarty | Last call was requested |
2015-12-02
|
08 | Kathleen Moriarty | Ballot approval text was generated |
2015-12-02
|
08 | Kathleen Moriarty | Ballot writeup was generated |
2015-12-02
|
08 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD is watching |
2015-12-02
|
08 | Kathleen Moriarty | Last call announcement was generated |
2015-12-02
|
08 | Kathleen Moriarty | Last call announcement was generated |
2015-11-30
|
08 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-08.txt |
2015-11-29
|
07 | Kathleen Moriarty | IESG state changed to AD is watching from Publication Requested |
2015-11-29
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Ron Bonica |
2015-11-29
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Ron Bonica |
2015-11-26
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2015-11-26
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2015-11-24
|
07 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-07.txt |
2015-11-23
|
06 | Kathleen Moriarty | Placed on agenda for telechat - 2015-12-17 |
2015-11-04
|
06 | Hannes Tschofenig | Shepherd Writeup for "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" draft-ietf-oauth-proof-of-possession-06 1. Summary The document shepherd is Kepeng Li. The responsible Area Director is … Shepherd Writeup for "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" draft-ietf-oauth-proof-of-possession-06 1. Summary The document shepherd is Kepeng Li. The responsible Area Director is Kathleen Moriarty. This specification defines how to express a declaration in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular key and that the recipient can cryptographically confirm proof-of- possession of the key by the presenter. This property is also sometimes described as the presenter being a holder-of-key. This specification is a Standards Track RFC describing a solution component described in the OAuth 2.0 Proof-of-Possession architecture (see draft-ietf-oauth-pop-architecture). 2. Review and Consensus The document was developed by the working group based on the requirements and architecture described in draft-ietf-oauth-pop-architecture. There is strong consensus behind this work. This document contains an IANA consideration section and requires registration into an existing registry and a new registry to be created. The document contains JSON examples, which have been validated using JSONLint. One example is only a JSON snippet and does not contain valid JSON. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. http://www.ietf.org/mail-archive/web/oauth/current/msg15005.html http://www.ietf.org/mail-archive/web/oauth/current/msg15004.html http://www.ietf.org/mail-archive/web/oauth/current/msg15001.html 4. Other Points All normative references have been finalized. |
2015-11-04
|
06 | Hannes Tschofenig | Responsible AD changed to Kathleen Moriarty |
2015-11-04
|
06 | Hannes Tschofenig | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-11-04
|
06 | Hannes Tschofenig | IESG state changed to Publication Requested |
2015-11-04
|
06 | Hannes Tschofenig | IESG process started in state Publication Requested |
2015-11-04
|
06 | Kepeng Li | Changed document writeup |
2015-11-04
|
06 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-06.txt |
2015-10-19
|
05 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-05.txt |
2015-10-14
|
04 | (System) | Notify list changed from "Derek Atkins" , "Kepeng Li" to (None) |
2015-10-11
|
04 | Kepeng Li | Changed document writeup |
2015-10-11
|
04 | Hannes Tschofenig | Notification list changed to "Derek Atkins" <derek@ihtfp.com>, "Kepeng Li" <kepeng.lkp@alibaba-inc.com> from "Derek Atkins" <derek@ihtfp.com> |
2015-10-11
|
04 | Hannes Tschofenig | Document shepherd changed to Kepeng Li |
2015-08-28
|
04 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-04.txt |
2015-07-06
|
03 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-03.txt |
2015-03-09
|
02 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-02.txt |
2015-03-04
|
01 | Hannes Tschofenig | Intended Status changed to Proposed Standard from None |
2015-03-04
|
01 | Hannes Tschofenig | Notification list changed to "Derek Atkins" <derek@ihtfp.com> |
2015-03-04
|
01 | Hannes Tschofenig | Document shepherd changed to Derek Atkins |
2015-01-28
|
01 | Michael Jones | New version available: draft-ietf-oauth-proof-of-possession-01.txt |
2014-08-25
|
00 | Hannes Tschofenig | This document now replaces draft-jones-oauth-proof-of-possession instead of None |
2014-07-21
|
00 | Hannes Tschofenig | New version available: draft-ietf-oauth-proof-of-possession-00.txt |