draft-ietf-oauth-proof-of-possession-07.txt		draft-ietf-oauth-proof-of-possession-08.txt
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track J. Bradley		Intended status: Standards Track J. Bradley
	Expires: May 27, 2016 Ping Identity		Expires: June 2, 2016 Ping Identity
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	November 24, 2015		November 30, 2015
	Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)		Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
	draft-ietf-oauth-proof-of-possession-07		draft-ietf-oauth-proof-of-possession-08
	Abstract		Abstract
	This specification defines how to express a declaration in a JSON Web		This specification defines how to express a declaration in a JSON Web
	Token (JWT) that the presenter of the JWT possesses a particular key		Token (JWT) that the presenter of the JWT possesses a particular key
	and that the recipient can cryptographically confirm proof-of-		and that the recipient can cryptographically confirm proof-of-
	possession of the key by the presenter. Being able to prove		possession of the key by the presenter. Being able to prove
	possession of a key is also sometimes described as the presenter		possession of a key is also sometimes described as the presenter
	being a holder-of-key.		being a holder-of-key.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 27, 2016.		This Internet-Draft will expire on June 2, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 2, line 31		skipping to change at page 2, line 31
	3.5. Representation of a URL for a Proof-of-Possession Key . . 9		3.5. Representation of a URL for a Proof-of-Possession Key . . 9
	3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10		3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 12		6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 12
	6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12		6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12
	6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12		6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12
	6.2.1. Registration Template . . . . . . . . . . . . . . . . 12		6.2.1. Registration Template . . . . . . . . . . . . . . . . 12
	6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13		6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . . 14		7.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 15		Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This specification defines how a JSON Web Token (JWT) [JWT] can		This specification defines how a JSON Web Token (JWT) [JWT] can
	declare that the presenter of the JWT possesses a key and that the		declare that the presenter of the JWT possesses a key and that the
	recipient can cryptographically confirm that the presenter possesses		recipient can cryptographically confirm that the presenter possesses
	that key. Proof-of-possession of a key is also sometimes described		that key. Proof-of-possession of a key is also sometimes described
	skipping to change at page 10, line 47		skipping to change at page 10, line 47
	All of the security considerations that are discussed in JWT [JWT]		All of the security considerations that are discussed in JWT [JWT]
	also apply here. In addition, proof-of-possession introduces its own		also apply here. In addition, proof-of-possession introduces its own
	unique security issues. Possessing a key is only valuable if it is		unique security issues. Possessing a key is only valuable if it is
	kept secret. Appropriate means must be used to ensure that		kept secret. Appropriate means must be used to ensure that
	unintended parties do not learn private key or symmetric key values.		unintended parties do not learn private key or symmetric key values.
	Proof-of-possession via encrypted symmetric secrets is subject to		Proof-of-possession via encrypted symmetric secrets is subject to
	replay attacks. This attack can be avoided when a signed nonce or		replay attacks. This attack can be avoided when a signed nonce or
	challenge is used, since the recipient can use a distinct nonce or		challenge is used, since the recipient can use a distinct nonce or
	challenged for each interaction.		challenge for each interaction.
	Similarly to other information included in a JWT, it is necessary to		Similarly to other information included in a JWT, it is necessary to
	apply data origin authentication and integrity protection (via a		apply data origin authentication and integrity protection (via a
	keyed message digest or a digital signature). Data origin		keyed message digest or a digital signature). Data origin
	authentication ensures that the recipient of the JWT learns about the		authentication ensures that the recipient of the JWT learns about the
	entity that created the JWT, since this will be important for any		entity that created the JWT, since this will be important for any
	policy decisions. Integrity protection prevents an adversary from		policy decisions. Integrity protection prevents an adversary from
	changing any elements conveyed within the JWT payload. Special care		changing any elements conveyed within the JWT payload. Special care
	has to be applied when carrying symmetric keys inside the JWT, since		has to be applied when carrying symmetric keys inside the JWT, since
	those not only require integrity protection, but also confidentiality		those not only require integrity protection, but also confidentiality
	protection.		protection.
	A recipient might not understand the "cnf" claim, in which case it		A recipient might not understand the "cnf" claim. Applications that
	will typically be ignored. Unless this is acceptable behavior,		require the proof-of-possession keys communicated with it to be
	applications that need the proof-of-possession keys communicated with		understood and processed must ensure that the parts of this
	it to be understood and processed must require that the parts of this		specification that they use are implemented.
	specification that they use be implemented.
			Applications utilizing proof-of-possession should also utilize
			audience restriction, as they provide different protections. Proof-
			of-possession can be used by recipients to reject messages from
			unauthorized senders. Audience restriction can be used by recipients
			to reject messages intended for different recipients.
	5. Privacy Considerations		5. Privacy Considerations
	A proof-of-possession key can be used as a correlation handle if the		A proof-of-possession key can be used as a correlation handle if the
	same key is used with multiple parties. Thus, for privacy reasons,		same key is used with multiple parties. Thus, for privacy reasons,
	it is recommended that different proof-of-possession keys be used		it is recommended that different proof-of-possession keys be used
	when interacting with different parties.		when interacting with different parties.
	6. IANA Considerations		6. IANA Considerations
	skipping to change at page 15, line 33		skipping to change at page 15, line 41
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors wish to thank Brian Campbell, Kepeng Li, James Manger,		The authors wish to thank Brian Campbell, Kepeng Li, James Manger,
	Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews		Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews
	of the specification.		of the specification.
	Appendix B. Document History		Appendix B. 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 ]]
			-08
			o Added security consideration about also utilizing audience
			restriction.
	-07		-07
	o Addressed review comments by Hannes Tschofenig, Kathleen Moriarty,		o Addressed review comments by Hannes Tschofenig, Kathleen Moriarty,
	and Justin Richer. Changes were:		and Justin Richer. Changes were:
	o Clarified that symmetric proof-of-possession keys can be generated		o Clarified that symmetric proof-of-possession keys can be generated
	by either the presenter or the issuer.		by either the presenter or the issuer.
	o Clarified that confirmation members that are not understood must		o Clarified that confirmation members that are not understood must
	be ignored unless otherwise specified by the application.		be ignored unless otherwise specified by the application.
End of changes. 8 change blocks.
	13 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/