< draft-ietf-oauth-pop-architecture-06.txt		draft-ietf-oauth-pop-architecture-07.txt >
	OAuth P. Hunt, Ed.		OAuth P. Hunt, Ed.
	Internet-Draft Oracle Corporation		Internet-Draft Oracle Corporation
	Intended status: Informational J. Richer		Intended status: Informational J. Richer
	Expires: May 27, 2016		Expires: June 3, 2016
	W. Mills		W. Mills
	P. Mishra		P. Mishra
	Oracle Corporation		Oracle Corporation
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	November 24, 2015		December 1, 2015
	OAuth 2.0 Proof-of-Possession (PoP) Security Architecture		OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
	draft-ietf-oauth-pop-architecture-06.txt		draft-ietf-oauth-pop-architecture-07.txt
	Abstract		Abstract
	The OAuth 2.0 bearer token specification, as defined in RFC 6750,		The OAuth 2.0 bearer token specification, as defined in RFC 6750,
	allows any party in possession of a bearer token (a "bearer") to get		allows any party in possession of a bearer token (a "bearer") to get
	access to the associated resources (without demonstrating possession		access to the associated resources (without demonstrating possession
	of a cryptographic key). To prevent misuse, bearer tokens must be		of a cryptographic key). To prevent misuse, bearer tokens must be
	protected from disclosure in transit and at rest.		protected from disclosure in transit and at rest.
	Some scenarios demand additional security protection whereby a client		Some scenarios demand additional security protection whereby a client
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 3, 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 6, line 48 ¶		skipping to change at page 6, line 48 ¶
	access token.		access token.
	Token repudiation:		Token repudiation:
	Token repudiation refers to a property whereby a resource server		Token repudiation refers to a property whereby a resource server
	is given an assurance that the authorization server cannot deny to		is given an assurance that the authorization server cannot deny to
	have created a token for the client.		have created a token for the client.
	5. Requirements		5. Requirements
	In contrast to bearer tokens [RFC6750] which call for tokens that are
	opaque to OAuth 2.0 clients, this specification defines the
	requirements for proof-of-possession ("PoP") tokens that may be
	parsed and verified by OAuth 2.0 clients and relying parties. In
	general, a "PoP" token enables an OAuth 2.0 client to demonstrate a
	proof-of-possession confirming the client's right to wield the token.
	RFC 4962 [RFC4962] gives useful guidelines for designers of		RFC 4962 [RFC4962] gives useful guidelines for designers of
	authentication and key management protocols. While RFC 4962 was		authentication and key management protocols. While RFC 4962 was
	written with the AAA framework used for network access authentication		written with the AAA framework used for network access authentication
	in mind the offered suggestions are useful for the design of other		in mind the offered suggestions are useful for the design of other
	key management systems as well. The following requirements list		key management systems as well. The following requirements list
	applies OAuth 2.0 terminology to the requirements outlined in RFC		applies OAuth 2.0 terminology to the requirements outlined in RFC
	4962.		4962.
	These requirements include		These requirements include
	skipping to change at page 10, line 51 ¶		skipping to change at page 10, line 44 ¶
	A number of the threats listed in Section 4 demand protection of the		A number of the threats listed in Section 4 demand protection of the
	access token content and a standardized solution, for example, in the		access token content and a standardized solution, for example, in the
	form of a JSON-based format, is available with the JWT [RFC7519].		form of a JSON-based format, is available with the JWT [RFC7519].
	6. Threat Mitigation		6. Threat Mitigation
	A large range of threats can be mitigated by protecting the content		A large range of threats can be mitigated by protecting the content
	of the token, for example using a digital signature or a keyed		of the token, for example using a digital signature or a keyed
	message digest. Alternatively, the content of the token could be		message digest. Alternatively, the content of the token could be
	passed by reference rather than by value (requiring a separate		passed by reference rather than by value (requiring a separate
	message exchange to resolve the reference to the token content). To		message exchange to resolve the reference to the token content).
	simplify the subsequent description we assume in the PoP architecture
	that the token itself is digitally signed by the authorization server		To simplify discussion in the following example we assume that the
	and therefore cannot be modified.		token itself cannot be modified by the client, either due to
			cryptographic protection (such as signature or encryption) or use of
			a reference value with sufficient entropy and associated secure
			lookup. The token remains opaque to the client. These are
			characteristics shared with bearer tokens and more information on
			best practices can be found in [RFC6819] and in the security
			considerations section of [RFC6750].
	To deal with token redirect it is important for the authorization		To deal with token redirect it is important for the authorization
	server to include the identifier of the intended recipient - the		server to include the identifier of the intended recipient - the
	resource server. A resource server must not be allowed to accept		resource server. A resource server must not be allowed to accept
	access tokens that are not meant for its consumption.		access tokens that are not meant for its consumption.
	To provide protection against token disclosure two approaches are		To provide protection against token disclosure two approaches are
	possible, namely (a) not to include sensitive information inside the		possible, namely (a) not to include sensitive information inside the
	token or (b) to ensure confidentiality protection. The latter		token or (b) to ensure confidentiality protection. The latter
	approach requires at least the communication interaction between the		approach requires at least the communication interaction between the
	skipping to change at page 20, line 26 ¶		skipping to change at page 20, line 26 ¶
	[I-D.ietf-oauth-pop-key-distribution]		[I-D.ietf-oauth-pop-key-distribution]
	Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,		Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
	"OAuth 2.0 Proof-of-Possession: Authorization Server to		"OAuth 2.0 Proof-of-Possession: Authorization Server to
	Client Key Distribution", draft-ietf-oauth-pop-key-		Client Key Distribution", draft-ietf-oauth-pop-key-
	distribution-02 (work in progress), October 2015.		distribution-02 (work in progress), October 2015.
	[I-D.ietf-oauth-proof-of-possession]		[I-D.ietf-oauth-proof-of-possession]
	Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	draft-ietf-oauth-proof-of-possession-06 (work in		draft-ietf-oauth-proof-of-possession-08 (work in
	progress), November 2015.		progress), November 2015.
	[I-D.ietf-oauth-signed-http-request]		[I-D.ietf-oauth-signed-http-request]
	Richer, J., Bradley, J., and H. Tschofenig, "A Method for		Richer, J., Bradley, J., and H. Tschofenig, "A Method for
	Signing an HTTP Requests for OAuth", draft-ietf-oauth-		Signing an HTTP Requests for OAuth", draft-ietf-oauth-
	signed-http-request-01 (work in progress), March 2015.		signed-http-request-01 (work in progress), March 2015.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
End of changes. 7 change blocks.
	16 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/