< draft-ietf-oauth-v2-19.txt		draft-ietf-oauth-v2-20.txt >
	Network Working Group E. Hammer-Lahav, Ed.		Network Working Group E. Hammer-Lahav, Ed.
	Internet-Draft Yahoo!		Internet-Draft Yahoo!
	Obsoletes: 5849 (if approved) D. Recordon		Obsoletes: 5849 (if approved) D. Recordon
	Intended status: Standards Track Facebook		Intended status: Standards Track Facebook
	Expires: January 26, 2012 D. Hardt		Expires: January 26, 2012 D. Hardt
	Microsoft		Microsoft
	July 25, 2011		July 25, 2011
	The OAuth 2.0 Authorization Protocol		The OAuth 2.0 Authorization Protocol
	draft-ietf-oauth-v2-19		draft-ietf-oauth-v2-20
	Abstract		Abstract
	The OAuth 2.0 authorization protocol enables a third-party		The OAuth 2.0 authorization protocol enables a third-party
	application to obtain limited access to an HTTP service, either on		application to obtain limited access to an HTTP service, either on
	behalf of a resource owner by orchestrating an approval interaction		behalf of a resource owner by orchestrating an approval interaction
	between the resource owner and the HTTP service, or by allowing the		between the resource owner and the HTTP service, or by allowing the
	third-party application to obtain access on its own behalf.		third-party application to obtain access on its own behalf.
	Status of this Memo		Status of this Memo
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	accomplished using a self-issued or third-party-issued assertion, or		accomplished using a self-issued or third-party-issued assertion, or
	by the authorization server performing client discovery using a		by the authorization server performing client discovery using a
	trusted channel.		trusted channel.
	2.1. Client Types		2.1. Client Types
	OAuth defines two client types, based on their ability to		OAuth defines two client types, based on their ability to
	authenticate securely with the authorization server (i.e. ability to		authenticate securely with the authorization server (i.e. ability to
	maintain the confidentiality of their client credentials):		maintain the confidentiality of their client credentials):
	private		confidential
	Clients capable of maintaining the confidentiality of their		Clients capable of maintaining the confidentiality of their
	credentials (e.g. client implemented on a secure server with		credentials (e.g. client implemented on a secure server with
	restricted access to the client credentials), or capable of secure		restricted access to the client credentials), or capable of secure
	client authentication using other means.		client authentication using other means.
	public		public
	Clients incapable of maintaining the confidentiality of their		Clients incapable of maintaining the confidentiality of their
	credentials (e.g. clients executing on the resource owner's device		credentials (e.g. clients executing on the resource owner's device
	such as an installed native application or a user-agent-based		such as an installed native application or a user-agent-based
	application), and incapable of secure client authentication via		application), and incapable of secure client authentication via
	any other mean.		any other mean.
	The client type designation is based on the authorization server's		The client type designation is based on the authorization server's
	definition of secure authentication and its acceptable exposure		definition of secure authentication and its acceptable exposure
	levels of client credentials.		levels of client credentials.
	This specification has been designed around the following client		This specification has been designed around the following client
	profiles:		profiles:
	web application		web application
	A web application is a private client running on a web server.		A web application is a confidential client running on a web
	Resource owners access the client via an HTML user interface		server. Resource owners access the client via an HTML user
	rendered in a user-agent on the resource owner's device. The		interface rendered in a user-agent on the resource owner's device.
	client credentials as well as any access token issued to the		The client credentials as well as any access token issued to the
	client are stored on the web server and are not exposed to or		client are stored on the web server and are not exposed to or
	accessible by the resource owner.		accessible by the resource owner.
	user-agent-based application		user-agent-based application
	A user-agent-based application is a public client in which the		A user-agent-based application is a public client in which the
	client code is downloaded from a web server and executes within a		client code is downloaded from a web server and executes within a
	user-agent on the resource owner's device. Protocol data and		user-agent on the resource owner's device. Protocol data and
	credentials are easily accessible (and often visible) to the		credentials are easily accessible (and often visible) to the
	resource owner. Since such applications reside within the user-		resource owner. Since such applications reside within the user-
	agent, they can make seamless use of the user-agent capabilities		agent, they can make seamless use of the user-agent capabilities
	when requesting authorization.		when requesting authorization.
	skipping to change at page 13, line 29 ¶		skipping to change at page 13, line 29 ¶
	2.3. Client Identifier		2.3. Client Identifier
	The authorization server issues the registered client a client		The authorization server issues the registered client a client
	identifier - a unique string representing the registration		identifier - a unique string representing the registration
	information provided by the client. The client identifier is not a		information provided by the client. The client identifier is not a
	secret, it is exposed to the resource owner, and cannot be used alone		secret, it is exposed to the resource owner, and cannot be used alone
	for client authentication.		for client authentication.
	2.4. Client Authentication		2.4. Client Authentication
	If the client type is private, the client and authorization server		If the client type is confidential, the client and authorization
	establish a client authentication method suitable for the security		server establish a client authentication method suitable for the
	requirements of the authorization server. The authorization server		security requirements of the authorization server. The authorization
	MAY accept any form of client authentication meeting its security		server MAY accept any form of client authentication meeting its
	requirements.		security requirements.
	Private clients are typically issued (or establish) a set of client		Confidential clients are typically issued (or establish) a set of
	credentials used for authenticating with the authorization server		client credentials used for authenticating with the authorization
	(e.g. password, public/private key pair).		server (e.g. password, public/private key pair).
	The authorization server SHOULD NOT make assumptions about the client		The authorization server SHOULD NOT make assumptions about the client
	type or accept the type information provided without establishing		type or accept the type information provided without establishing
	trust with the client or its developer. The authorization server MAY		trust with the client or its developer. The authorization server MAY
	establish a client authentication method with public clients.		establish a client authentication method with public clients.
	However, the authorization server MUST NOT rely on public client		However, the authorization server MUST NOT rely on public client
	authentication for the purpose of identifying the client.		authentication for the purpose of identifying the client.
	The client MUST NOT use more than one authentication method in each		The client MUST NOT use more than one authentication method in each
	request.		request.
	skipping to change at page 17, line 7 ¶		skipping to change at page 17, line 7 ¶
	the client. The authorization server redirects the user-agent to the		the client. The authorization server redirects the user-agent to the
	client's redirection endpoint previously established with the		client's redirection endpoint previously established with the
	authorization server during the client registration process or when		authorization server during the client registration process or when
	initiating the authorization request.		initiating the authorization request.
	The redirection endpoint URI MUST be an absolute URI as defined by		The redirection endpoint URI MUST be an absolute URI as defined by
	[RFC3986] section 4.3, MAY include a query component which MUST be		[RFC3986] section 4.3, MAY include a query component which MUST be
	retained by the authorization server when adding additional query		retained by the authorization server when adding additional query
	parameters, and MUST NOT include a fragment component.		parameters, and MUST NOT include a fragment component.
	3.1.2.1. Endpoint Confidentiality		3.1.2.1. Endpoint Request Confidentiality
	If a redirection request will result in the transmission of an		If a redirection request will result in the transmission of an
	authorization code or access token over an open network (between the		authorization code or access token over an open network (between the
	resource owner's user-agent and the client), the client SHOULD		resource owner's user-agent and the client), the client SHOULD
	require the use of a transport-layer security mechanism.		require the use of a transport-layer security mechanism.
	Lack of transport-layer security can have a severe impact on the		Lack of transport-layer security can have a severe impact on the
	security of the client and the protected resources it is authorized		security of the client and the protected resources it is authorized
	to access. The use of transport-layer security is particularly		to access. The use of transport-layer security is particularly
	critical when the authorization process is used as a form of		critical when the authorization process is used as a form of
	skipping to change at page 18, line 26 ¶		skipping to change at page 18, line 26 ¶
	from being used as an open redirector.		from being used as an open redirector.
	3.1.2.5. Endpoint Content		3.1.2.5. Endpoint Content
	The redirection request to the client's endpoint typically results in		The redirection request to the client's endpoint typically results in
	an HTML document response, processed by the user-agent. If the HTML		an HTML document response, processed by the user-agent. If the HTML
	response is served directly as the result of the redirection request,		response is served directly as the result of the redirection request,
	any script included in the HTML document will execute with full		any script included in the HTML document will execute with full
	access to the redirection URI and the credentials it contains.		access to the redirection URI and the credentials it contains.
	The client SHOULD NOT include any third-party scripts in the
	redirection endpoint response. Instead, it should extract the
	credentials from the URI and redirect the user-agent again to another
	endpoint without the credentials in the URI.
	The client MUST NOT include any untrusted third-party scripts in the		The client MUST NOT include any untrusted third-party scripts in the
	redirection endpoint response (e.g. third-party analytics, social		redirection endpoint response (e.g. third-party analytics, social
	plug-ins, ad networks) without first ensuring that its own scripts		plug-ins, ad networks) without first ensuring that its own scripts
	used to extract and remove the credentials from the URI will execute		used to extract and remove the credentials from the URI will execute
	first.		first.
			The client SHOULD NOT include any third-party scripts in the
			redirection endpoint response. Instead, it should extract the
			credentials from the URI and redirect the user-agent again to another
			endpoint without the credentials in the URI.
	3.2. Token Endpoint		3.2. Token Endpoint
	The token endpoint is used by the client to obtain an access token by		The token endpoint is used by the client to obtain an access token by
	presenting its authorization grant or refresh token. The token		presenting its authorization grant or refresh token. The token
	endpoint is used with every authorization grant except for the		endpoint is used with every authorization grant except for the
	implicit grant type (since an access token is issued directly).		implicit grant type (since an access token is issued directly).
	The means through which the client obtains the location of the token		The means through which the client obtains the location of the token
	endpoint are beyond the scope of this specification but is typically		endpoint are beyond the scope of this specification but is typically
	provided in the service documentation. The endpoint URI MAY include		provided in the service documentation. The endpoint URI MAY include
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 20 ¶
	The client MUST use the HTTP "POST" method when making access token		The client MUST use the HTTP "POST" method when making access token
	requests.		requests.
	Parameters sent without a value MUST be treated as if they were		Parameters sent without a value MUST be treated as if they were
	omitted from the request. The authorization server SHOULD ignore		omitted from the request. The authorization server SHOULD ignore
	unrecognized request parameters. Request and response parameters		unrecognized request parameters. Request and response parameters
	MUST NOT be included more than once.		MUST NOT be included more than once.
	3.2.1. Client Authentication		3.2.1. Client Authentication
	Private clients, clients issued client credentials, or clients		Confidential clients, clients issued client credentials, or clients
	assigned other authentication requirements, MUST authenticate with		assigned other authentication requirements, MUST authenticate with
	the authorization server as described in Section 2.4 when making		the authorization server as described in Section 2.4 when making
	requests to the token endpoint. Client authentication is used for:		requests to the token endpoint. Client authentication is used for:
	o Enforcing the binding of refresh tokens and authorization codes to		o Enforcing the binding of refresh tokens and authorization codes to
	the client they are issued. Client authentication is critical		the client they are issued. Client authentication is critical
	when an authorization code is transmitted to the redirection		when an authorization code is transmitted to the redirection
	endpoint over an insecure channel, or when the redirection URI has		endpoint over an insecure channel, or when the redirection URI has
	not been registered in full.		not been registered in full.
	o Recovery from a compromised client by disabling the client or		o Recovery from a compromised client by disabling the client or
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 10 ¶
	To request an access token, the client obtains authorization from the		To request an access token, the client obtains authorization from the
	resource owner. The authorization is expressed in the form of an		resource owner. The authorization is expressed in the form of an
	authorization grant which the client uses to request the access		authorization grant which the client uses to request the access
	token. OAuth defines four grant types: authorization code, implicit,		token. OAuth defines four grant types: authorization code, implicit,
	resource owner password credentials, and client credentials. It also		resource owner password credentials, and client credentials. It also
	provides an extension mechanism for defining additional grant types.		provides an extension mechanism for defining additional grant types.
	4.1. Authorization Code		4.1. Authorization Code
	The authorization code grant type is used to obtain both access		The authorization code grant type is used to obtain both access
	tokens and refresh tokens and is optimized for private clients. As a		tokens and refresh tokens and is optimized for confidential clients.
	redirection-based flow, the client must be capable of interacting		As a redirection-based flow, the client must be capable of
	with the resource owner's user-agent (typically a web browser) and		interacting with the resource owner's user-agent (typically a web
	capable of receiving incoming requests (via redirection) from the		browser) and capable of receiving incoming requests (via redirection)
	authorization server.		from the authorization server.
	+----------+		+----------+
	| resource |		| resource |
	| owner |		| owner |
	| |		| |
	+----------+		+----------+
	^		^
	|		|
	(B)		(B)
	+----|-----+ Client Identifier +---------------+		+----|-----+ Client Identifier +---------------+
	skipping to change at page 25, line 13 ¶		skipping to change at page 25, line 13 ¶
	REQUIRED. Value MUST be set to "authorization_code".		REQUIRED. Value MUST be set to "authorization_code".
	code		code
	REQUIRED. The authorization code received from the		REQUIRED. The authorization code received from the
	authorization server.		authorization server.
	redirect_uri		redirect_uri
	REQUIRED, if the "redirect_uri" parameter was included in the		REQUIRED, if the "redirect_uri" parameter was included in the
	authorization request described in Section 4.1.1, and their		authorization request described in Section 4.1.1, and their
	values MUST be identical.		values MUST be identical.
	If the client type is private or was issued client credentials (or		If the client type is confidential or was issued client credentials
	assigned other authentication requirements), the client MUST		(or assigned other authentication requirements), the client MUST
	authenticate with the authorization server as described in		authenticate with the authorization server as described in
	Section 3.2.1.		Section 3.2.1.
	For example, the client makes the following HTTP using transport-		For example, the client makes the following HTTP using transport-
	layer security (extra line breaks are for display purposes only):		layer security (extra line breaks are for display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA		grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	The authorization server MUST:		The authorization server MUST:
	o require client authentication for private clients or for any		o require client authentication for confidential clients or for any
	client issued client credentials (or with other authentication		client issued client credentials (or with other authentication
	requirements),		requirements),
	o authenticate the client if client authentication is included and		o authenticate the client if client authentication is included and
	ensure the authorization code was issued to the authenticated		ensure the authorization code was issued to the authenticated
	client,		client,
	o verify that the authorization code is valid, and		o verify that the authorization code is valid, and
	o ensure that the "redirect_uri" parameter is present if the		o ensure that the "redirect_uri" parameter is present if the
	"redirect_uri" parameter was included in the initial authorization		"redirect_uri" parameter was included in the initial authorization
	request described in Section 4.1.1, and that their values are		request described in Section 4.1.1, and that their values are
	identical.		identical.
	skipping to change at page 33, line 26 ¶		skipping to change at page 33, line 26 ¶
	password		password
	REQUIRED. The resource owner password, encoded as UTF-8.		REQUIRED. The resource owner password, encoded as UTF-8.
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited, case sensitive strings. The value is		of space-delimited, case sensitive strings. The value is
	defined by the authorization server. If the value contains		defined by the authorization server. If the value contains
	multiple space-delimited strings, their order does not matter,		multiple space-delimited strings, their order does not matter,
	and each string adds an additional access range to the		and each string adds an additional access range to the
	requested scope.		requested scope.
	If the client type is private or was issued client credentials (or		If the client type is confidential or was issued client credentials
	assigned other authentication requirements), the client MUST		(or assigned other authentication requirements), the client MUST
	authenticate with the authorization server as described in		authenticate with the authorization server as described in
	Section 3.2.1.		Section 3.2.1.
	For example, the client makes the following HTTP request using		For example, the client makes the following HTTP request using
	transport-layer security (extra line breaks are for display purposes		transport-layer security (extra line breaks are for display purposes
	only):		only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=password&username=johndoe&password=A3ddj3w		grant_type=password&username=johndoe&password=A3ddj3w
	The authorization server MUST:		The authorization server MUST:
	o require client authentication for private clients or for any		o require client authentication for confidential clients or for any
	client issued client credentials (or with other authentication		client issued client credentials (or with other authentication
	requirements),		requirements),
	o authenticate the client if client authentication is included, and		o authenticate the client if client authentication is included, and
	o validate the resource owner password credentials.		o validate the resource owner password credentials.
	Since this access token request utilizes the resource owner's		Since this access token request utilizes the resource owner's
	password, the authorization server MUST protect the endpoint against		password, the authorization server MUST protect the endpoint against
	brute force attacks.		brute force attacks.
	4.3.3. Access Token Response		4.3.3. Access Token Response
	skipping to change at page 34, line 42 ¶		skipping to change at page 34, line 42 ¶
	4.4. Client Credentials		4.4. Client Credentials
	The client can request an access token using only its client		The client can request an access token using only its client
	credentials (or other supported means of authentication) when the		credentials (or other supported means of authentication) when the
	client is requesting access to the protected resources under its		client is requesting access to the protected resources under its
	control, or those of another resource owner which has been previously		control, or those of another resource owner which has been previously
	arranged with the authorization server (the method of which is beyond		arranged with the authorization server (the method of which is beyond
	the scope of this specification).		the scope of this specification).
	The client credentials grant type MUST only be used by private		The client credentials grant type MUST only be used by confidential
	clients.		clients.
	+---------+ +---------------+		+---------+ +---------------+
	| | | |		| | | |
	| |>--(A)- Client Authentication --->| Authorization |		| |>--(A)- Client Authentication --->| Authorization |
	| Client | | Server |		| Client | | Server |
	| |<--(B)---- Access Token ---------<| |		| |<--(B)---- Access Token ---------<| |
	| | | |		| | | |
	+---------+ +---------------+		+---------+ +---------------+
	skipping to change at page 41, line 7 ¶		skipping to change at page 41, line 7 ¶
	defined by the authorization server. If the value contains		defined by the authorization server. If the value contains
	multiple space-delimited strings, their order does not matter,		multiple space-delimited strings, their order does not matter,
	and each string adds an additional access range to the		and each string adds an additional access range to the
	requested scope. The requested scope MUST be equal or lesser		requested scope. The requested scope MUST be equal or lesser
	than the scope originally granted by the resource owner, and if		than the scope originally granted by the resource owner, and if
	omitted is treated as equal to the scope originally granted by		omitted is treated as equal to the scope originally granted by
	the resource owner.		the resource owner.
	Because refresh tokens are typically long-lasting credentials used to		Because refresh tokens are typically long-lasting credentials used to
	request additional access tokens, the refresh token is bound to the		request additional access tokens, the refresh token is bound to the
	client it was issued. If the client type is private or was issued		client it was issued. If the client type is confidential or was
	client credentials (or assigned other authentication requirements),		issued client credentials (or assigned other authentication
	the client MUST authenticate with the authorization server as		requirements), the client MUST authenticate with the authorization
	described in Section 3.2.1.		server as described in Section 3.2.1.
	For example, the client makes the following HTTP request using		For example, the client makes the following HTTP request using
	transport-layer security (extra line breaks are for display purposes		transport-layer security (extra line breaks are for display purposes
	only):		only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA		grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
	The authorization server MUST:		The authorization server MUST:
	o require client authentication for private clients or for any		o require client authentication for confidential clients or for any
	client issued client credentials (or with other authentication		client issued client credentials (or with other authentication
	requirements),		requirements),
	o authenticate the client if client authentication is included and		o authenticate the client if client authentication is included and
	ensure the refresh token was issued to the authenticated client,		ensure the refresh token was issued to the authenticated client,
	o validate the refresh token, and		o validate the refresh token, and
	If valid and authorized, the authorization server issues an access		If valid and authorized, the authorization server issues an access
	token as described in Section 5.1. If the request failed		token as described in Section 5.1. If the request failed
	verification or is invalid, the authorization server returns an error		verification or is invalid, the authorization server returns an error
	response as described in Section 5.2.		response as described in Section 5.2.
	skipping to change at page 51, line 33 ¶		skipping to change at page 51, line 33 ¶
	using an access token associated with the attacker's account rather		using an access token associated with the attacker's account rather
	than the victim's. Depending on the nature of the client and the		than the victim's. Depending on the nature of the client and the
	protected resources, this can have undesirable and damaging effects.		protected resources, this can have undesirable and damaging effects.
	It is strongly RECOMMENDED that the client includes the "state"		It is strongly RECOMMENDED that the client includes the "state"
	request parameter with authorization requests to the authorization		request parameter with authorization requests to the authorization
	server. The "state" request parameter MUST contain a non-guessable		server. The "state" request parameter MUST contain a non-guessable
	value, and the client MUST keep it in a location accessible only by		value, and the client MUST keep it in a location accessible only by
	the client or the user-agent (i.e., protected by same-origin policy).		the client or the user-agent (i.e., protected by same-origin policy).
	For example, using a DOM variable (protected by JavaScript or other		For example, using a DOM variable, HTTP cookie, or HTML5 client-side
	DOM-binding language's enforcement of SOP [[ add reference ]]), HTTP		storage. The authorization server includes the value of the "state"
	cookie, or HTML5 client-side storage. The authorization server		parameter when redirecting the user-agent back to the client which
	includes the value of the "state" parameter when redirecting the		MUST then ensure the received value matches the stored value.
	user-agent back to the client which MUST then ensure the received
	value matches the stored value.
	10.13. Clickjacking		10.13. Clickjacking
	[[ Rework to use specification terminology ]]		In a clickjacking attack, an attacker registers a legitimate client
			and then constructs a malicious site in which it loads the
	Clickjacking is the process of tricking end-users into revealing		authorization server's authorization endpoint web page in a
	confidential information or taking control of their device while		transparent iframe overlaid on top of a set of dummy buttons which
	clicking on seemingly innocuous web pages. In more detail, a		are carefully constructed to be placed directly under important
	malicious site loads the target site in a transparent iframe overlaid		buttons on the authorization page. When an end-user clicks a
	on top of a set of dummy buttons which are carefully constructed to		misleading visible button, the end-user is actually clicking an
	be placed directly under important buttons on the target site. When		invisible button on the authorization page (such as an "Authorize"
	a user clicks a visible button, they are actually clicking a button		button). This allows an attacker to trick a resource owner into
	(such as an "Authorize" button) on the hidden page.		granting its client access without their knowledge.
	To prevent clickjacking (and phishing attacks), native applications		To prevent this form of attack, native applications SHOULD use
	SHOULD use external browsers instead of embedding browsers in an		external browsers instead of embedding browsers in an iframe when
	iframe when requesting end-user authorization. For newer browsers,		requesting end-user authorization. For most newer browsers,
	avoidance of iframes can be enforced by the authorization server		avoidance of iframes can be enforced by the authorization server
	using the "x-frame-options" header [[ Add reference ]]. This header		using the (non-standard) "x-frame-options" header. This header can
	can have two values, "deny" and "sameorigin", which will block any		have two values, "deny" and "sameorigin", which will block any
	framing or framing by sites with a different origin, respectively.		framing, or framing by sites with a different origin, respectively.
	For older browsers, javascript framebusting techniques can be used		For older browsers, javascript framebusting techniques can be used
	but may not be effective in all browsers.		but may not be effective in all browsers.
	10.14. Code Injection and Input Validation		10.14. Code Injection and Input Validation
	A code injection attack occurs when an input or otherwise external		A code injection attack occurs when an input or otherwise external
	variable is used by an application in which that input can cause		variable is used by an application in which that input can cause
	modification of the application logic when used unsanitized. This		modification of the application logic when used unsanitized. This
	may allow an attacker to gain access to the application device or its		may allow an attacker to gain access to the application device or its
	data, cause denial of service, or a wide range of malicious side-		data, cause denial of service, or a wide range of malicious side-
	skipping to change at page 61, line 41 ¶		skipping to change at page 61, line 41 ¶
	Recommendation REC-html401-19991224, December 1999,		Recommendation REC-html401-19991224, December 1999,
	<http://www.w3.org/TR/1999/REC-html401-19991224>.		<http://www.w3.org/TR/1999/REC-html401-19991224>.
	13.2. Informative References		13.2. Informative References
	[I-D.draft-hardt-oauth-01]		[I-D.draft-hardt-oauth-01]
	Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth		Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
	Web Resource Authorization Profiles", January 2010.		Web Resource Authorization Profiles", January 2010.
	[I-D.ietf-oauth-saml2-bearer]		[I-D.ietf-oauth-saml2-bearer]
	Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion		Mortimore, C., "SAML 2.0 Bearer Assertion Grant Type
	Grant Type Profile for OAuth 2.0",		Profile for OAuth 2.0", draft-ietf-oauth-saml2-bearer-04
	draft-ietf-oauth-saml2-bearer-03 (work in progress),		(work in progress), May 2011.
	February 2011.
	[I-D.ietf-oauth-v2-bearer]		[I-D.ietf-oauth-v2-bearer]
	Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0		Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
	Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04		Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-06
	(work in progress), March 2011.		(work in progress), June 2011.
	[I-D.ietf-oauth-v2-http-mac]		[I-D.ietf-oauth-v2-http-mac]
	Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP		Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP
	Authentication: MAC Access Authentication",		Authentication: MAC Access Authentication",
	draft-ietf-oauth-v2-http-mac-00 (work in progress),		draft-ietf-oauth-v2-http-mac-00 (work in progress),
	May 2011.		May 2011.
	[I-D.ietf-oauth-v2-threatmodel]		[I-D.ietf-oauth-v2-threatmodel]
	Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0		Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations",		Threat Model and Security Considerations",
End of changes. 23 change blocks.
	66 lines changed or deleted		63 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/