draft-ietf-ace-cwt-proof-of-possession-10.txt | draft-ietf-ace-cwt-proof-of-possession-11.txt | |||
---|---|---|---|---|
ACE M. Jones | ACE M. Jones | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Intended status: Standards Track L. Seitz | Intended status: Standards Track L. Seitz | |||
Expires: May 2, 2020 RISE SICS | Expires: May 3, 2020 RISE SICS | |||
G. Selander | G. Selander | |||
Ericsson AB | Ericsson AB | |||
S. Erdtman | S. Erdtman | |||
Spotify | Spotify | |||
H. Tschofenig | H. Tschofenig | |||
Arm Ltd. | Arm Ltd. | |||
October 30, 2019 | October 31, 2019 | |||
Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) | Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) | |||
draft-ietf-ace-cwt-proof-of-possession-10 | draft-ietf-ace-cwt-proof-of-possession-11 | |||
Abstract | Abstract | |||
This specification describes how to declare in a CBOR Web Token (CWT) | This specification describes how to declare in a CBOR Web Token (CWT) | |||
(which is defined by RFC 8392) that the presenter of the CWT | (which is defined by RFC 8392) that the presenter of the CWT | |||
possesses a particular proof-of-possession key. Being able to prove | possesses a particular proof-of-possession key. Being able to prove | |||
possession of a key is also sometimes described as being the holder- | possession of a key is also sometimes described as being the holder- | |||
of-key. This specification provides equivalent functionality to | of-key. This specification provides equivalent functionality to | |||
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC | "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC | |||
7800) but using Concise Binary Object Representation (CBOR) and CWTs | 7800) but using Concise Binary Object Representation (CBOR) and CWTs | |||
skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 2, 2020. | This Internet-Draft will expire on May 3, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 10, line 31 ¶ | skipping to change at page 10, line 31 ¶ | |||
However, to allow for the allocation of values prior to publication, | However, to allow for the allocation of values prior to publication, | |||
the Designated Experts may approve registration once they are | the Designated Experts may approve registration once they are | |||
satisfied that such a specification will be published. [[ Note to | satisfied that such a specification will be published. [[ Note to | |||
the RFC Editor: The name of the mailing list should be determined in | the RFC Editor: The name of the mailing list should be determined in | |||
consultation with the IESG and IANA. Suggested name: cwt-reg- | consultation with the IESG and IANA. Suggested name: cwt-reg- | |||
review@ietf.org. ]] | review@ietf.org. ]] | |||
Registration requests sent to the mailing list for review should use | Registration requests sent to the mailing list for review should use | |||
an appropriate subject (e.g., "Request to Register CWT Confirmation | an appropriate subject (e.g., "Request to Register CWT Confirmation | |||
Method: example"). Registration requests that are undetermined for a | Method: example"). Registration requests that are undetermined for a | |||
period longer than 21 days can be brought to the IESG's attention | period longer than 21 days can be brought directly to IANA's | |||
(using the iesg@ietf.org mailing list) for resolution. | attention (using the iana@iana.org mailing list) for resolution. | |||
Designated Experts should determine whether a registration request | Designated Experts should determine whether a registration request | |||
contains enough information for the registry to be populated with the | contains enough information for the registry to be populated with the | |||
new values and whether the proposed new functionality already exists. | new values and whether the proposed new functionality already exists. | |||
In the case of an incomplete registration or an attempt to register | In the case of an incomplete registration or an attempt to register | |||
already existing functionality, the Designated Experts should ask for | already existing functionality, the Designated Experts should ask for | |||
corrections or reject the registration. | corrections or reject the registration. | |||
It is suggested that multiple Designated Experts be appointed who are | It is suggested that multiple Designated Experts be appointed who are | |||
able to represent the perspectives of different applications using | able to represent the perspectives of different applications using | |||
skipping to change at page 14, line 36 ¶ | skipping to change at page 14, line 36 ¶ | |||
Vyncke, and Jim Schaad. | Vyncke, and Jim Schaad. | |||
Ludwig Seitz and Goeran Selander worked on this document as part of | Ludwig Seitz and Goeran Selander worked on this document as part of | |||
the CelticPlus projects CyberWI and CRITISEC, with funding from | the CelticPlus projects CyberWI and CRITISEC, with funding from | |||
Vinnova. | Vinnova. | |||
Document History | Document History | |||
[[ to be removed by the RFC Editor before publication as an RFC ]] | [[ to be removed by the RFC Editor before publication as an RFC ]] | |||
-11 | ||||
o Addressed remaining IESG review comment by Mirja Kuehlewind. | ||||
-10 | -10 | |||
o Addressed IESG review comments by Adam Roach and Eric Vyncke. | o Addressed IESG review comments by Adam Roach and Eric Vyncke. | |||
-09 | -09 | |||
o Addressed Gen-ART review comments by Christer Holmberg and SecDir | o Addressed Gen-ART review comments by Christer Holmberg and SecDir | |||
review comments by Yoav Nir. | review comments by Yoav Nir. | |||
-08 | -08 | |||
End of changes. 6 change blocks. | ||||
6 lines changed or deleted | 10 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |