draft-ietf-oauth-proof-of-possession-00.txt		draft-ietf-oauth-proof-of-possession-01.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: January 22, 2015 Ping Identity		Expires: August 1, 2015 Ping Identity
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	July 21, 2014		January 28, 2015
	Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)		Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
	draft-ietf-oauth-proof-of-possession-00.txt		draft-ietf-oauth-proof-of-possession-01
	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. This property is also		possession of the key by the presenter. This property is also
	sometimes described as the presenter being a holder-of-key.		sometimes described as the presenter being a holder-of-key.
	Status of This Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 22, 2015.		This Internet-Draft will expire on August 1, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Proof-Of-Possession Representation . . . . . . . . . . . . . 3		3. Proof-Of-Possession Representation . . . . . . . . . . . . . . 4
	3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . 4		3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . . 4
	3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . 4		3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . . 5
	3.3. Confirmation . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Specifics Intentionally Not Specified . . . . . . . . . . 6		3.4. Specifics Intentionally Not Specified . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5.1. JSON Web Token Claims Registration . . . . . . . . . . . 8		5.1. JSON Web Token Claims Registration . . . . . . . . . . . . 8
	5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8		5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
	5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 8		5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 8
	5.2.1. Registration Template . . . . . . . . . . . . . . . . 8		5.2.1. Registration Template . . . . . . . . . . . . . . . . 9
	5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 9		5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 10		Appendix C. Document History . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	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) [JWT] that the presenter of the JWT possesses a		Token (JWT) [JWT] that the presenter of the JWT possesses a
	particular key and that the recipient can cryptographically confirm		particular key and that the recipient can cryptographically confirm
	proof-of-possession of the key by the presenter. This property is		proof-of-possession of the key by the presenter. This property is
	also sometimes described as the presenter being a holder-of-key.		also sometimes described as the presenter being a holder-of-key.
	[[ Editorial Note: This paragraph needs to be updated to provide more		[[ Editorial Note: This paragraph needs to be updated to provide more
	context and possibly also to describe the use of asymmetric keys		context and possibly also to describe the use of asymmetric keys
	instead. It's not clear that the symmetric case is as useful or		instead. It's not clear that the symmetric case is as useful or
	valuable, and it is certainly more complicated.]] Envision the		valuable, and it is certainly more complicated.]] Envision the
	following use case: An OAuth 2.0 authorization server generates a JWT		following use case: An OAuth 2.0 authorization server generates a JWT
	and places an encrypted symmetric key inside the newly introduced		and places an encrypted symmetric key inside the newly introduced
	confirmation claim. This symmetric key is encrypted with a key known		confirmation claim. This symmetric key is encrypted with a key known
	only to the authorization server and the recipient. The JWT is then		only to the authorization server and the recipient. The JWT is then
	sent to the presenter. Since the presenter is unable to obtain the		sent to the presenter. Since the presenter is unable to obtain the
	encrypted symmetric key, the authorization server conveys that		encrypted symmetric key, the authorization server conveys that
	symmetric key separately to the presenter. Now, the presenter is in		symmetric key separately to the presenter. Now, the presenter is in
	possession of the symmetric key as well as the JWT (which includes		possession of the symmetric key as well as the JWT (which includes
	the confirmation claim member). When the presenter needs to utilize		the confirmation claim member). When the presenter needs to utilize
	the JWT to at recipient, it also needs to demonstrate possession of		the JWT to at recipient, it also needs to demonstrate possession of
	skipping to change at page 6, line 26		skipping to change at page 6, line 46
	are intentionally not described in this specification, as different		are intentionally not described in this specification, as different
	protocols will communicate this information in different ways.		protocols will communicate this information in different ways.
	Likewise, the means of communicating the signed nonce is also not		Likewise, the means of communicating the signed nonce is also not
	specified, as this is also protocol-specific.		specified, as this is also protocol-specific.
	Note that another means of proving possession of the key when it is a		Note that another means of proving possession of the key when it is a
	symmetric key is to encrypt the key to the recipient. The means of		symmetric key is to encrypt the key to the recipient. The means of
	obtaining a key for the recipient is likewise protocol-specific.		obtaining a key for the recipient is likewise protocol-specific.
	For an example specification that uses the mechanisms defined in this		For an example specification that uses the mechanisms defined in this
	document, see [I-D.hunt-oauth-pop-architecture].		document, see [I-D.ietf-oauth-pop-architecture].
	4. Security Considerations		4. Security Considerations
	All of the normal security issues, especially in relationship to		All of the normal security issues, especially in relationship to
	comparing URIs and dealing with unrecognized values, that are		comparing URIs and dealing with unrecognized values, that are
	discussed in JWT [JWT] also apply here.		discussed in JWT [JWT] also apply here.
	In addition, proof-of-possession introduces its own unique security		In addition, proof-of-possession introduces its own unique security
	issues. Possessing the key is only valuable if it is kept secret.		issues. Possessing the key is only valuable if it is kept secret.
	Appropriate means must be used to ensure that unintended parties do		Appropriate means must be used to ensure that unintended parties do
	skipping to change at page 7, line 12		skipping to change at page 7, line 32
	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 may not understand the newly introduced "cnf" claim and		A recipient may not understand the newly introduced "cnf" claim and
	may consequently treat it as a bearer token. While this is a		may consequently treat it as a bearer token. While this is a
	legitimate concern, it is outside the scope of this specification,		legitimate concern, it is outside the scope of this specification,
	since demonstration the possession of the key associated with the		since demonstration the possession of the key associated with the
	"cnf" claim is not covered by this specification. For more details,		"cnf" claim is not covered by this specification. For more details,
	please consult [I-D.hunt-oauth-pop-architecture].		please consult [I-D.ietf-oauth-pop-architecture].
	5. IANA Considerations		5. IANA Considerations
	The following registration procedure is used for all the registries		The following registration procedure is used for all the registries
	established by this specification.		established by this specification.
	Values are registered with a Specification Required [RFC5226] after a		Values are registered with a Specification Required [RFC5226] after a
	two-week review period on the [TBD]@ietf.org mailing list, on the		two-week review period on the [TBD]@ietf.org mailing list, on the
	advice of one or more Designated Experts. However, to allow for the		advice of one or more Designated Experts. However, to allow for the
	allocation of values prior to publication, the Designated Expert(s)		allocation of values prior to publication, the Designated Expert(s)
	may approve registration once they are satisfied that such a		may approve registration once they are satisfied that such a
	specification will be published.		specification will be published.
	Registration requests must be sent to the [TBD]@ietf.org mailing list		Registration requests must be sent to the [TBD]@ietf.org mailing list
	for review and comment, with an appropriate subject (e.g., "Request		for review and comment, with an appropriate subject (e.g., "Request
	for access token type: example"). [[ Note to the RFC Editor: The		for access token type: example"). [[ Note to the RFC Editor: The name
	name of the mailing list should be determined in consultation with		of the mailing list should be determined in consultation with the
	the IESG and IANA. Suggested name: jwt-reg-review. ]]		IESG and IANA. Suggested name: jwt-reg-review. ]]
	Within the review period, the Designated Expert(s) will either		Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision		approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation		to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request		and, if applicable, suggestions as to how to make the request
	successful. Registration requests that are undetermined for a period		successful. Registration requests that are undetermined for a period
	longer than 21 days can be brought to the IESG's attention (using the		longer than 21 days can be brought to the IESG's attention (using the
	iesg@iesg.org mailing list) for resolution.		iesg@iesg.org mailing list) for resolution.
	Criteria that should be applied by the Designated Expert(s) includes		Criteria that should be applied by the Designated Expert(s) includes
	determining whether the proposed registration duplicates existing		determining whether the proposed registration duplicates existing
	skipping to change at page 9, line 24		skipping to change at page 9, line 46
	Web Key		Web Key
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3 of [[ this document ]]		o Specification Document(s): Section 3 of [[ this document ]]
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	draft-ietf-jose-json-web-encryption (work in progress),		draft-ietf-jose-json-web-encryption (work in progress),
	July 2014.		January 2015.
	[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-		[JWK] Jones, M., "JSON Web Key (JWK)",
	key (work in progress), July 2014.		draft-ietf-jose-json-web-key (work in progress),
			January 2015.
	[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", draft-ietf-oauth-json-web-token (work in		(JWT)", draft-ietf-oauth-json-web-token (work in
	progress), July 2014.		progress), December 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	6.2. Informative References		6.2. Informative References
	[I-D.hunt-oauth-pop-architecture]		[I-D.ietf-oauth-pop-architecture]
	Hunt, P., Richer, J., Mills, W., Mishra, P., and H.		Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
	Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security		Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
	Architecture", draft-hunt-oauth-pop-architecture-02 (work		Architecture", draft-ietf-oauth-pop-architecture-00 (work
	in progress), June 2014.		in progress), July 2014.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	Markup Language (SAML) V2.0", OASIS Standard saml-core-		Markup Language (SAML) V2.0", OASIS Standard saml-core-
	2.0-os, March 2005.		2.0-os, March 2005.
	Appendix A. Open Issues		Appendix A. Open Issues
	In some conversations, we have said that it is the issuer of the JWT		In some conversations, we have said that it is the issuer of the JWT
	skipping to change at page 10, line 27		skipping to change at page 10, line 49
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	The authors wish to thank James Manger for his review of the		The authors wish to thank James Manger for his review of the
	specification.		specification.
	Appendix C. Document History		Appendix C. 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 ]]
	-02
	o Used the same section structuring conventions as the JWT
	specification.
	o Reverted some changes introduced in -01 without adequate prior
	review.
	o Applied some editorial corrections.
	-01		-01
			o Updated references.
	o Updated affiliation.
	o Various editorial changes.
	o Updates to the security considerations section based on review
	feedback by James Manager.
	o Included the kid element in the examples (as requested by James
	Manger).
	o Expanded the introduction section.
	o Moved the terminology/RFC2119 boilerplate text from the
	introduction to a separate terminology section.
	-00		-00
	o Wrote the first draft.		o Created the initial working group draft from
			draft-jones-oauth-proof-of-possession-02.
	Authors' Addresses		Authors' Addresses
	Michael B. Jones		Michael B. Jones
	Microsoft		Microsoft
	Email: mbj@microsoft.com		Email: mbj@microsoft.com
	URI: http://self-issued.info/		URI: http://self-issued.info/
	John Bradley		John Bradley
End of changes. 19 change blocks.
	61 lines changed or deleted		45 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/