< draft-hoyer-valid-00.txt		draft-hoyer-valid-01.txt >
	Network Working Group P. Hoyer		Network Working Group P. Hoyer
	Internet-Draft ActivIdentity		Internet-Draft ActivIdentity
	Intended status: Standards Track T. Moses		Intended status: Standards Track T. Moses
	Expires: January 7, 2010 Entrust		Expires: July 31, 2010 Entrust
	M. Pei		M. Pei
	VeriSign		VeriSign
	S. Machani		S. Machani
	Diversinet		Diversinet
	July 6, 2009		January 27, 2010
	VALID		VALID
	draft-hoyer-valid-00		draft-hoyer-valid-01
			Abstract
			This document describes a Web-service interface standard for an
			authentication-data validation service that supports risk-based,
			multi-factor authentication.This standard enables enterprises to
			deploy best-of-breed solutions combining components from different
			vendors into the same infrastructure.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 45 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 7, 2010.		This Internet-Draft will expire on July 31, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document describes a Web-service interface standard for an		described in the BSD License.
	authentication-data validation service that supports risk-based,
	multi-factor authentication.This standard enables enterprises to
	deploy best-of-breed solutions combining components from different
	vendors into the same infrastructure.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Authentication-Data Validation Service Interface overview . . 7		2. Authentication-Data Validation Service Interface overview . . 7
	2.1. Authentication data communication . . . . . . . . . . . . 7		2.1. Authentication data communication . . . . . . . . . . . . 7
	2.2. Verified attributes . . . . . . . . . . . . . . . . . . . 7		2.2. Verified attributes . . . . . . . . . . . . . . . . . . . 7
	2.3. Challenge/response . . . . . . . . . . . . . . . . . . . . 7		2.3. Challenge/response . . . . . . . . . . . . . . . . . . . . 7
	2.4. Token collections . . . . . . . . . . . . . . . . . . . . 8		2.4. Token collections . . . . . . . . . . . . . . . . . . . . 8
	3. Communication patterns . . . . . . . . . . . . . . . . . . . . 9		3. Communication patterns . . . . . . . . . . . . . . . . . . . . 9
	3.1. In-band authentication . . . . . . . . . . . . . . . . . . 9		3.1. In-band authentication . . . . . . . . . . . . . . . . . . 9
	3.2. Out-of-band challenge . . . . . . . . . . . . . . . . . . 10		3.1.1. In-band Challenge/Response . . . . . . . . . . . . . . 9
	3.3. Out-of-band response . . . . . . . . . . . . . . . . . . . 11		3.1.2. In-band 2 way Challenge/Response . . . . . . . . . . . 10
	3.4. Client supplies challenge . . . . . . . . . . . . . . . . 12		3.2. Out-of-band challenge . . . . . . . . . . . . . . . . . . 11
	3.5. End-user obtains assertions Out-of-band from server . . . 12		3.3. Out-of-band response . . . . . . . . . . . . . . . . . . . 12
	4. Asynchronous communication . . . . . . . . . . . . . . . . . . 14		3.4. Client supplies challenge . . . . . . . . . . . . . . . . 13
	4.1. Out-of-band challenge . . . . . . . . . . . . . . . . . . 14		3.5. End-user obtains assertions Out-of-band from server . . . 13
	4.2. Out-of-band response . . . . . . . . . . . . . . . . . . . 14		4. Asynchronous communication . . . . . . . . . . . . . . . . . . 15
	5. Authentication moving factor resync . . . . . . . . . . . . . 15		4.1. Out-of-band challenge . . . . . . . . . . . . . . . . . . 15
	5.1. Automatic re-sync based on authentication data . . . . . . 15		4.2. Out-of-band response . . . . . . . . . . . . . . . . . . . 15
	5.2. Manual re-sync based on presenting moving factor values . 15		5. User centric and device centric (pseudonymous)
	6. Policy models . . . . . . . . . . . . . . . . . . . . . . . . 16		authentication models . . . . . . . . . . . . . . . . . . . . 16
	7. Common message contents . . . . . . . . . . . . . . . . . . . 18		5.1. User Centric authentication model . . . . . . . . . . . . 16
	7.1. Request Security Token . . . . . . . . . . . . . . . . . . 18		5.2. Device Centric authentication model . . . . . . . . . . . 16
	7.2. Request Security Token Response . . . . . . . . . . . . . 19		6. Authentication moving factor resync . . . . . . . . . . . . . 17
	8. Mechanism-specific message contents . . . . . . . . . . . . . 21		6.1. Automatic re-sync based on authentication data . . . . . . 17
	9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 22		6.2. Manual re-sync based on presenting moving factor values . 17
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		7. Policy models . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. XML namespace registration . . . . . . . . . . . . . . . . 23		8. Common message contents . . . . . . . . . . . . . . . . . . . 20
	10.2. VALID Version Registry . . . . . . . . . . . . . . . . . . 23		8.1. Request Security Token . . . . . . . . . . . . . . . . . . 20
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 24		8.2. Request Security Token Response . . . . . . . . . . . . . 21
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25		9. Mechanism-specific message contents . . . . . . . . . . . . . 23
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 24
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 26		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	13.2. Informative References . . . . . . . . . . . . . . . . . . 27		11.1. XML namespace registration . . . . . . . . . . . . . . . . 25
	Appendix A. WSDL . . . . . . . . . . . . . . . . . . . . . . . . 28		11.2. VALID Version Registry . . . . . . . . . . . . . . . . . . 25
	Appendix B. Mechanism specific message contents . . . . . . . . . 30		12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	B.1. Username/password . . . . . . . . . . . . . . . . . . . . 30		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	B.2. In band one-time-password (OTP) . . . . . . . . . . . . . 31		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.3. In band challenge/response . . . . . . . . . . . . . . . . 32		14.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	B.4. Out-of-band challenge . . . . . . . . . . . . . . . . . . 34		14.2. Informative References . . . . . . . . . . . . . . . . . . 29
	B.5. Out-of-band response . . . . . . . . . . . . . . . . . . . 35		Appendix A. WSDL . . . . . . . . . . . . . . . . . . . . . . . . 30
	B.6. Client supplies challenge . . . . . . . . . . . . . . . . 37		Appendix B. Mechanism specific message contents . . . . . . . . . 32
	B.7. Challenge/response with signature . . . . . . . . . . . . 38		B.1. Username/password . . . . . . . . . . . . . . . . . . . . 32
	Appendix C. Use Cases . . . . . . . . . . . . . . . . . . . . . . 40		B.2. In band one-time-password (OTP) . . . . . . . . . . . . . 33
	C.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . 40		B.3. In band one-time-password (OTP) token synchronization . . 35
	C.1.1. OTP Validation . . . . . . . . . . . . . . . . . . . . 40		B.4. In band challenge/response . . . . . . . . . . . . . . . . 37
			B.5. Out-of-band challenge . . . . . . . . . . . . . . . . . . 39
			B.6. Out-of-band response . . . . . . . . . . . . . . . . . . . 40
			B.7. Client supplies challenge . . . . . . . . . . . . . . . . 42
			B.8. Challenge/response with signature . . . . . . . . . . . . 43
			Appendix C. Use Cases . . . . . . . . . . . . . . . . . . . . . . 45
			C.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . 45
			C.1.1. OTP Validation . . . . . . . . . . . . . . . . . . . . 45
	C.1.2. Challenge/Response Validation - Server generated		C.1.2. Challenge/Response Validation - Server generated
	challenge . . . . . . . . . . . . . . . . . . . . . . 40		challenge . . . . . . . . . . . . . . . . . . . . . . 45
	C.1.3. Challenge/Response Validation - User generated		C.1.3. Challenge/Response Validation - User generated
	challenge . . . . . . . . . . . . . . . . . . . . . . 41		challenge . . . . . . . . . . . . . . . . . . . . . . 46
	C.1.4. OTP Validation + Server managed PIN . . . . . . . . . 41		C.1.4. 2-way mutual Challenge/Response Validation . . . . . . 46
	C.1.5. MatrixCardValidation - Server generated challenge . . 41		C.1.5. OTP Validation + Server managed PIN . . . . . . . . . 46
	C.2. Synchornisation Use Cases . . . . . . . . . . . . . . . . 41		C.1.6. MatrixCardValidation - Server generated challenge . . 46
	C.2.1. OTP Token Auto-Resync (NextOTP) . . . . . . . . . . . 41		C.2. Synchronisation Use Cases . . . . . . . . . . . . . . . . 46
	C.2.2. OTP Token Manual-resync . . . . . . . . . . . . . . . 41		C.2.1. OTP Token Resync with the Next OTPs . . . . . . . . . 47
	Appendix D. Requirements . . . . . . . . . . . . . . . . . . . . 42		C.2.2. OTP Token Resync with Moving Factor . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43		Appendix D. Requirements . . . . . . . . . . . . . . . . . . . . 48
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	The Authentication-Data Validation Service Interface definition		The Authentication-Data Validation Service Interface definition
	(VALID) describes a Web-service interface for a validation server.		(VALID) describes a Web-service interface for a validation server.
	The specification reuses data definitions from [SAML], [WS-Security]		The specification reuses data definitions from [SAML], [WS-Security]
	and [WS-Trust] and operates over version 1.2 of [SOAP]. Upon		and [WS-Trust] and operates over version 1.2 of [SOAP]. Upon
	successful validation, the validation server returns a SAML assertion		successful validation, the validation server returns a SAML assertion
	containing verified attributes of the authenticated end-user or a		containing verified attributes of the authenticated end-user or a
	hardware or software device under the end-user's control.		hardware or software device under the end-user's control.
	skipping to change at page 4, line 50 ¶		skipping to change at page 4, line 50 ¶
	alternatives.		alternatives.
	The characters "(" and ")" are used to indicate that contained		The characters "(" and ")" are used to indicate that contained
	items are to be treated as a group with respect to cardinality or		items are to be treated as a group with respect to cardinality or
	choice.		choice.
	The characters "[" and "]" are used to call out references and		The characters "[" and "]" are used to call out references and
	property names.		property names.
	Additional child elements and/or attributes MAY be added at the		Additional child elements and/or attributes MAY be added at the
	indicated extension points (see Section 9) but MUST NOT contradict		indicated extension points (see Section 10) but MUST NOT
	the semantics of the parent and/or owner, respectively. By		contradict the semantics of the parent and/or owner, respectively.
	default, if a receiver does not recognize an extension, the		By default, if a receiver does not recognize an extension, the
	receiver SHOULD ignore the extension; exceptions to this		receiver SHOULD ignore the extension; exceptions to this
	processing rule, if any, are clearly indicated below.		processing rule, if any, are clearly indicated below.
	XML namespace prefixes (see Table 1) are used to indicate the		XML namespace prefixes (see Table 1) are used to indicate the
	namespace of the element being defined.		namespace of the element being defined.
	Elements and Attributes defined by this specification are referred		Elements and Attributes defined by this specification are referred
	to in the text of this document using XPath 1.0 expressions.		to in the text of this document using XPath 1.0 expressions.
	Extensibility points are referred to using an extended version of		Extensibility points are referred to using an extended version of
	this syntax:		this syntax:
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	An attribute extensibility point is referred to using @{any} in		An attribute extensibility point is referred to using @{any} in
	place of the attribute name. This indicates that any attribute		place of the attribute name. This indicates that any attribute
	name can be used, from any namespace other than the namespace		name can be used, from any namespace other than the namespace
	of this specification		of this specification
	1.3. Namespaces		1.3. Namespaces
	The following XML namespace prefixes are used in the specification.		The following XML namespace prefixes are used in the specification.
	env: http://www.w3.org/2003/05/soap-envelope		env: http://www.w3.org/2003/05/soap-envelope
			pskc: urn:ietf:params:xml:ns:keyprov:pskc
	saml: urn:oasis:names:tc:SAML:2.0:assertion		saml: urn:oasis:names:tc:SAML:2.0:assertion
	valid: urn:ietf:params:xml:ns:valid		valid: urn:ietf:params:xml:ns:valid
	wsp: http://www.w3.org/ns/ws-policy		wsp: http://www.w3.org/ns/ws-policy
	wss: http://docs.oasis-open.org/wss/2004/01/		wss: http://docs.oasis-open.org/wss/2004/01/
	oasis-200401-wss-wssecurity-secext-1.0		oasis-200401-wss-wssecurity-secext-1.0
	wst: http://docs.oasis-open.org/ws-sx/ws-trust/200512		wst: http://docs.oasis-open.org/ws-sx/ws-trust/200512
	wst14: http://docs.oasis-open.org/ws-sx/ws-trust/200802		wst14: http://docs.oasis-open.org/ws-sx/ws-trust/200802
	xsd: http://www.w3.org/2001/XMLSchema		xsd: http://www.w3.org/2001/XMLSchema
	1.4. Terminology		1.4. Terminology
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 35 ¶
	In-band authentication		In-band authentication
	The end-user accesses the application (1). The application supplies		The end-user accesses the application (1). The application supplies
	the authentication data to the validation server and receives an		the authentication data to the validation server and receives an
	assertion in return (2).		assertion in return (2).
	For in-band challenge/response authentication mechanisms, additional		For in-band challenge/response authentication mechanisms, additional
	messages between the end-user and the validation server MUST be		messages between the end-user and the validation server MUST be
	relayed by the application.		relayed by the application.
			3.1.1. In-band Challenge/Response
			__________ _____________
			| | | |
			| End-user |------------------------->| Application |
			|__________| 1. Access application |_____________|
			4. In-band challenge /|\ \
			5. In-band response | |
			2. Request assertion | > VALID
			3. return challenge | |
			6. obtain assertion | |
			_____\|/____ /
			| |
			| Validation |
			| server |
			|____________|
			Figure 1: In-band Challenge/Response
			The "in-band challenge/response" pattern is shown in Figure 1. The
			application invokes the validation server (2). The validation server
			returns a challenge (3). The application passes the challenge to the
			end-user (4). The end-user may or may not transform the challenge
			and sends the result to the validation server in-band (5). The
			application supplies the authentication data to the validation server
			and receives an assertion in return (6).
			3.1.2. In-band 2 way Challenge/Response
			__________ _____________
			| | | |
			| End-user |------------------------------>| Application |
			|__________| 1. In-band client challenge |_____________|
			4. In-band server resp & challenge /|\ \
			5. In-band client response | |
			2. Request assertion | > VALID
			3. return server resp & | |
			server challenge | |
			6. obtain assertion | |
			_____\|/____ /
			| |
			| Validation |
			| server |
			|____________|
			Figure 2: In-band 2 way Challenge/Response
			The "In-band 2 way challenge/response" pattern is shown in Figure 2.
			This pattern is based on the In-band Challenge/Response pattern but
			authenticates both the server and the client. The application
			receives an in-band client challenge (1). The application invokes
			the validation server (2). The validation server returns the
			response to the client challenge and a server challenge (3). The
			application passes the server response and server challenge to the
			end-user (4). The end-user may or may not transform the server
			challenge and after verifying the server response sends the result to
			the validation server in-band (5). The application supplies the
			authentication data to the validation server and receives an
			assertion in return (6).
	3.2. Out-of-band challenge		3.2. Out-of-band challenge
	__________ _____________		__________ _____________
	| | | |		| | | |
	-->| End-user |--------------------->| Application |		-->| End-user |--------------------->| Application |
	| |__________| 1. Access |_____________|		| |__________| 1. Access |_____________|
	| application | \		| application | \
	| | |		| | |
	| 4. In-band | |		| 4. In-band | |
	| Response | |		| Response | |
	skipping to change at page 15, line 5 ¶		skipping to change at page 16, line 5 ¶
	valid:Pending		valid:Pending
	The validation server, upon sending this value, and the application,		The validation server, upon sending this value, and the application,
	upon receiving it, SHALL terminate the current session.		upon receiving it, SHALL terminate the current session.
	Both parties MUST maintain the <wst:RequestSecurityToken/@Context>		Both parties MUST maintain the <wst:RequestSecurityToken/@Context>
	attribute as metadata associated with the initial session. In the		attribute as metadata associated with the initial session. In the
	subsequent session, they MUST use this <wst:RequestSecurityToken/@		subsequent session, they MUST use this <wst:RequestSecurityToken/@
	Context> attribute value to correlate the challenge and response.		Context> attribute value to correlate the challenge and response.
	5. Authentication moving factor resync		5. User centric and device centric (pseudonymous) authentication models
			There are two authentication models supported by this specification:
			5.1. User Centric authentication model
			In this model the mapping between a specific user and the devices
			that belong to the specific user is known and managed by the
			validation server. This means that the authentication request will
			contain explicit user information in form of a UserId
			5.2. Device Centric authentication model
			In this model the validation server does not have any knowledge to
			whom a specific device belongs. The user-device mapping will be at
			the appllication or service provider. This means that the
			authentication request MUST NOT contain uer information and that it
			MUST contain information to uniquely identify the device by using the
			<DeviceInfo> element as defined in [PSKC].
			6. Authentication moving factor resync
	Some authentication schemes gradually lose synchronization between		Some authentication schemes gradually lose synchronization between
	client and server. In order to compensate for this, the server must		client and server. In order to compensate for this, the server must
	accept authentication data values within a range, or window of the		accept authentication data values within a range, or window of the
	moving factor (e.g. the event counter used in event based one time		moving factor (e.g. the event counter used in event based one time
	password algorithms, see [HOTP]). When an authentication moving		password algorithms, see [HOTP]). When an authentication moving
	factor drifts to the edge of, or beyond, the server's window for a		factor drifts to the edge of, or beyond, the server's window for a
	particular end-user, the server has to adjust its window. This		particular end-user, the server has to adjust its window. This
	process is known as resyncing.		process is known as resyncing.
	Resyncing erodes assurance in the authentication event. So,		Resyncing erodes assurance in the authentication event. So,
	following a resync event, the validation server commonly requests a		following a resync event, the validation server commonly requests a
	second authentication data value, which effectively restores the		second authentication data value, which effectively restores the
	level of assurance provided by the authentication.		level of assurance provided by the authentication.
	The following two approaches to resyncing exist:		The following two approaches to resyncing exist:
	5.1. Automatic re-sync based on authentication data		6.1. Automatic re-sync based on authentication data
	In this approach, the resynchronisation is based only on the		In this approach, the resynchronisation is based only on the
	authentication data. In this apporach the server searches through an		authentication data. In this apporach the server searches through an
	extended window of the moving factor(s) to see if it can match the		extended window of the moving factor(s) to see if it can match the
	presented authentication data. In this apporach two OTPs MUST be		presented authentication data. In this apporach two OTPs MUST be
	transmitted so that the server MUST try to match the first OTP with		transmitted so that the server MUST try to match the first OTP with
	the extended window and also MUST match the second OTP with a normal		the extended window and also MUST match the second OTP with a normal
	window.		window.
	5.2. Manual re-sync based on presenting moving factor values		6.2. Manual re-sync based on presenting moving factor values
	In this approach to resynchronisation, the server is given the exact		In this approach to resynchronisation, the server is given the exact
	value of the moving factor (e.g. the event counter value in [HOTP])		value of the moving factor (e.g. the event counter value in [HOTP])
	together with the OTP. The server MUST only set the moving factor(s)		together with the OTP. The server MUST only set the moving factor(s)
	to the received value if the OTP matches successfully (given the new		to the received value if the OTP matches successfully (given the new
	moving factor values).		moving factor values).
	6. Policy models		7. Policy models
	Authentication policy defines the requirements for accessing a		Authentication policy defines the requirements for accessing a
	resource in terms of mechanisms and their strengths, expressible in		resource in terms of mechanisms and their strengths, expressible in
	disjunctive normal form (that is a disjunction ("OR") of conjunctions		disjunctive normal form (that is a disjunction ("OR") of conjunctions
	("AND"s)). This approach supports risk-based multi-factor		("AND"s)). This approach supports risk-based multi-factor
	authentication.		authentication.
	Two policy models are supported. In the first model (see figuer		Two policy models are supported. In the first model (see figuer
	below), the application is responsible for invoking the right		below), the application is responsible for invoking the right
	combination of validation servers in order to satisfy the		combination of validation servers in order to satisfy the
	skipping to change at page 18, line 5 ¶		skipping to change at page 20, line 5 ¶
	In either model, the application MAY supply information about the		In either model, the application MAY supply information about the
	resource to which access is requested in a <wsp:AppliesTo> element.		resource to which access is requested in a <wsp:AppliesTo> element.
	The validation server MAY restrict the resources to which the		The validation server MAY restrict the resources to which the
	application SHALL limit access by including a <wsp:AppliesTo> element		application SHALL limit access by including a <wsp:AppliesTo> element
	in its response. This is not intended as an access-control solution;		in its response. This is not intended as an access-control solution;
	it is intended only to enforce an appropriate level of authentication		it is intended only to enforce an appropriate level of authentication
	assurance, based on the sensitivity of the resource, where the		assurance, based on the sensitivity of the resource, where the
	sensitivity is not uniform across all the resources accessible by the		sensitivity is not uniform across all the resources accessible by the
	application.		application.
	7. Common message contents		8. Common message contents
	This section describes the mechanism-independent requirements for		This section describes the mechanism-independent requirements for
	message contents.		message contents.
	7.1. Request Security Token		8.1. Request Security Token
	The message-independent requirements for "request security token"		The message-independent requirements for "request security token"
	messages are shown in this example:		messages are shown in this example:
	<wst:RequestSecurityToken Context=" ... ">		<wst:RequestSecurityToken Context=" ... ">
	<wst:TokenType>		<wst:TokenType>
	http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0		http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
	</wst:TokenType>		</wst:TokenType>
	<wst:RequestType>		<wst:RequestType>
	http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue		http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
	skipping to change at page 19, line 11 ¶		skipping to change at page 21, line 11 ¶
	validation server. Even if the validation server cannot provide		validation server. Even if the validation server cannot provide
	all the requested attributes, it SHOULD proceed with the		all the requested attributes, it SHOULD proceed with the
	validation process.		validation process.
	<wst:Lifetime> - OPTIONAL The client MAY specify the lifetime of the		<wst:Lifetime> - OPTIONAL The client MAY specify the lifetime of the
	requested assertion using this element. The server MUST verify		requested assertion using this element. The server MUST verify
	that the requested lifetime conforms with its own policy for		that the requested lifetime conforms with its own policy for
	assertion lifetimes.		assertion lifetimes.
	<wst:RequestSecurityToken/@Context> - MANDATORY This attribute MUST		<wst:RequestSecurityToken/@Context> - MANDATORY This attribute MUST
	be set by the client. The server MUST use the value as the <wst:		be set by the client. It is an opaque value to the server. The
	RequestSecurityToken/@Context> value in the response.		server MUST use the value as the <wst:RequestSecurityToken/@
			Context> value in the response.
	7.2. Request Security Token Response		8.2. Request Security Token Response
	The common requirements for the final "request security token		The common requirements for the final "request security token
	response" message are shown in this example:		response" message are shown in this example:
	<wst:RequestSecurityTokenResponse Context=" ... ">		<wst:RequestSecurityTokenResponse Context=" ... ">
	<wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>
	...		...
	</wst:RequestedSecurityToken>		</wst:RequestedSecurityToken>
	<wst:Claims Dialect="...">		<wst:Claims Dialect="...">
	<saml:Attribute/> +		<saml:Attribute/> +
	skipping to change at page 19, line 40 ¶		skipping to change at page 21, line 41 ¶
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	If the authentication data failed to validate, then the server MUST		If the authentication data failed to validate, then the server MUST
	include the <env:Body/env:Fault> element containing the value wst:		include the <env:Body/env:Fault> element containing the value wst:
	FailedAuthentication. In this case, it SHALL NOT include any other		FailedAuthentication. In this case, it SHALL NOT include any other
	elements.		elements.
	If the authentication data failed to validate due to missing		If the authentication data failed to validate due to missing
	authentication data, then the server MUST include the <env:Body/		authentication data, then the server MUST include the <env:Body/
	env:Fault> element containing the value valid:		env:Fault> element containing the value valid:
	MissingAuthenticationData. In this case, it SHALL NOT include any		MissingAuthenticationData. The server can optionally include
	other elements.		elements indicating which authentication data is missing.
	<wst:RequestedSecurityToken> - OPTIONAL - Zero or more If validation		<wst:RequestedSecurityToken> - OPTIONAL - Zero or more If validation
	is complete and successful, then the server SHALL include a SAML		is complete and successful, then the server SHALL include a SAML
	assertion containing verified end-user attributes. Otherwise this		assertion containing verified end-user attributes. Otherwise this
	element SHALL be omitted. The server SHOULD set the assertion		element SHALL be omitted. The server SHOULD set the assertion
	lifetime in accordance with the lifetime specified in the request,		lifetime in accordance with the lifetime specified in the request,
	or its own policy, whichever is more restrictive.		or its own policy, whichever is more restrictive.
	<wst:RequestType> - MANDATORY The client SHALL set the value		<wst:RequestType> - MANDATORY The client SHALL set the value
	'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If		'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If
	skipping to change at page 21, line 5 ¶		skipping to change at page 23, line 5 ¶
	<wpt:AppliesTo> - OPTIONAL If the authentication assurance level		<wpt:AppliesTo> - OPTIONAL If the authentication assurance level
	achieved is suitable only for a sub-set of resources, the		achieved is suitable only for a sub-set of resources, the
	validation server MUST set a value that identifies that sub-		validation server MUST set a value that identifies that sub-
	set.The client SHOULD restrict access to resources falling within		set.The client SHOULD restrict access to resources falling within
	the sub-set defined by this element.		the sub-set defined by this element.
	<wst:RequestSecurityToken/@Context> - MANDATORY The server MUST		<wst:RequestSecurityToken/@Context> - MANDATORY The server MUST
	include the @Context value from the request. The client SHOULD		include the @Context value from the request. The client SHOULD
	load the context identified by the value.		load the context identified by the value.
	8. Mechanism-specific message contents		9. Mechanism-specific message contents
	The mechanism-specific requirements for message contents are		The mechanism-specific requirements for message contents are
	described in the appendices. These MAY be used in any combination.		described in the appendices. These MAY be used in any combination.
	9. Extensibility		10. Extensibility
	This section lists a few common extension points provided by VALID:		This section lists a few common extension points provided by VALID:
	New VALID Version: Whenever it is necessary to define a new version		New VALID Version: Whenever it is necessary to define a new version
	of this document then a new version number has to be allocated to		of this document then a new version number has to be allocated to
	refer to the new specification version. The rules for		refer to the new specification version. The rules for
	extensibililty are defined in Section 10.		extensibililty are defined in Section 11.
	10. IANA Considerations		11. IANA Considerations
	10.1. XML namespace registration		11.1. XML namespace registration
	This section registers a new XML namespace,		This section registers a new XML namespace,
	"urn:ietf:params:xml:ns:valid", per the guidelines in [RFC3688].		"urn:ietf:params:xml:ns:valid", per the guidelines in [RFC3688].
	URI: urn:ietf:params:xml:ns:valid		URI: urn:ietf:params:xml:ns:valid
	Registrant Contact: Philip Hoyer (phoyer@actividentity.com).		Registrant Contact: Philip Hoyer (phoyer@actividentity.com).
	XML:		XML:
	skipping to change at page 23, line 39 ¶		skipping to change at page 25, line 39 ¶
	<h1>Namespace for VALID</h1>		<h1>Namespace for VALID</h1>
	<h2>urn:ietf:params:xml:ns:valid</h2>		<h2>urn:ietf:params:xml:ns:valid</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	10.2. VALID Version Registry		11.2. VALID Version Registry
	IANA is requested to create a registry for VALID version numbers.		IANA is requested to create a registry for VALID version numbers.
	The registry has the following structure:		The registry has the following structure:
	VALID Version | Specification		VALID Version | Specification
	+---------------------------+----------------		+---------------------------+----------------
	| 1.0 | [This document]		| 1.0 | [This document]
	Standards action is required to define new versions of VALID. It is		Standards action is required to define new versions of VALID. It is
	not envisioned to depreciate, delete, or modify existing VALID		not envisioned to depreciate, delete, or modify existing VALID
	versions.		versions.
	11. Security Considerations		12. Security Considerations
	The validation server SHOULD authenticate the client and limit access		The validation server SHOULD authenticate the client and limit access
	to the validation service only to authorized clients. This MAY be		to the validation service only to authorized clients. This MAY be
	achieved by object level security (e.g xml signatures as defined in		achieved by object level security (e.g xml signatures as defined in
	[XMLDSIG] applied to the <env:Header> and <env:Body> elements),		[XMLDSIG] applied to the <env:Header> and <env:Body> elements),
	transport layer security (e.g. [TLS]) or network layer security		transport layer security (e.g. [TLS]) or network layer security
	(e.g. isolated network segment).		(e.g. isolated network segment).
	The application MAY authenticate the validation server. This MAY be		The application MAY authenticate the validation server. This MAY be
	achieved by object level security (e.g. xml signatures as defined in		achieved by object level security (e.g. xml signatures as defined in
	[XMLDSIG] applied to the <env:Header> and <env:Body> elements or		[XMLDSIG] applied to the <env:Header> and <env:Body> elements or
	assertion), transport layer security (e.g. TLS) or network layer		assertion), transport layer security (e.g. TLS) or network layer
	security (e.g. isolated network segment).		security (e.g. isolated network segment).
	The chosen authentication mechanism MUST ensure freshness of the		The chosen authentication mechanism MUST ensure freshness of the
	exchanges in order to detect replay attacks.		exchanges in order to detect replay attacks.
	Privacy of the authentication data and end-user attributes MAY also		Privacy of the authentication data and end-user attributes MAY also
	require protection.		require protection.
	12. Acknowledgements		13. Acknowledgements
	The authors of this draft would like to thank the following people		The authors of this draft would like to thank the following people
	for their feedback: Siddharth Bajaj, David M'Raihi, Mike Davis and		for their feedback: Siddharth Bajaj, David M'Raihi, Mike Davis and
	Peter Tapling.		Peter Tapling.
	This work is based on earlier work by the members of OATH (Initiative		This work is based on earlier work by the members of OATH (Initiative
	for Open AuTHentication), see [OATH], to specify a format that can be		for Open AuTHentication), see [OATH], to specify a format that can be
	freely distributed to the technical community.		freely distributed to the technical community.
	13. References		14. References
	13.1. Normative References		14.1. Normative References
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	skipping to change at page 27, line 9 ¶		skipping to change at page 29, line 9 ¶
	Specification, Feb 2006.		Specification, Feb 2006.
	[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",		[XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing",
	URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,		URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
	W3C Recommendation, February 2002.		W3C Recommendation, February 2002.
	[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",		[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
	URL: http://www.w3.org/TR/xmlenc-core/,		URL: http://www.w3.org/TR/xmlenc-core/,
	W3C Recommendation, December 2002.		W3C Recommendation, December 2002.
	13.2. Informative References		14.2. Informative References
	[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and		[HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
	O. Ranen, "HOTP: An HMAC-Based One Time Password		O. Ranen, "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226, December 2005.		Algorithm", RFC 4226, December 2005.
	[OATH] "Initiative for Open AuTHentication",		[OATH] "Initiative for Open AuTHentication",
	URL: http://www.openauthentication.org.		URL: http://www.openauthentication.org.
	[OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.		[OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.
	Bhajaj, "OCRA: OATH Challenge-Response Algorithms", URL:		Bhajaj, "OCRA: OATH Challenge-Response Algorithms", URL:
	http://docs.oasis-open.org/security/saml/v2.0/		http://docs.oasis-open.org/security/saml/v2.0/
	saml-core-2.0-os.pdf, IETF Standard draft, January 2008.		saml-core-2.0-os.pdf, IETF Standard draft, January 2008.
			[PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
			Key Container (PSKC)",
			URL: http://tools.ietf.org/html/
			draft-ietf-keyprov-pskc-05, IETF Standard draft,
			January 2010.
	[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.		[RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.
	Masinter, "Uniform Resource Identifiers (URI): Generic		Masinter, "Uniform Resource Identifiers (URI): Generic
	Syntax", BCP 26, RFC 2396, August 1998.		Syntax", BCP 26, RFC 2396, August 1998.
	[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.
	[XMLNS] "Namespaces in XML", W3C Recommendation ,		[XMLNS] "Namespaces in XML", W3C Recommendation ,
	URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,		URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
	January 1999.		January 1999.
	Appendix A. WSDL		Appendix A. WSDL
	The validation server WSDL is shown here.		The validation server WSDL is shown here.
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<definitions targetNamespace="urn:ietf:params:xml:ns:valid"		<definitions targetNamespace="urn:ietf:params:xml:ns:valid"
	xmlns:valid="urn:ietf:params:xml:ns:valid"		xmlns:valid="urn:ietf:params:xml:ns:valid"
			xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"		xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
	xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"		xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
	xmlns:wss="http://docs.oasis-open.org/wss/2004/01/		xmlns:wss="http://docs.oasis-open.org/wss/2004/01/
	oasis-200401-wss-wssecurity-secext-1.0"		oasis-200401-wss-wssecurity-secext-1.0"
	xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"		xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
	xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"		xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"
	xmlns:wsp="http://www.w3.org/ns/ws-policy"		xmlns:wsp="http://www.w3.org/ns/ws-policy"
	xmlns="http://schemas.xmlsoap.org/wsdl/">		xmlns="http://schemas.xmlsoap.org/wsdl/">
	<types>		<types>
	skipping to change at page 28, line 36 ¶		skipping to change at page 30, line 37 ¶
	xmlns:wss="http://docs.oasis-open.org/wss/2004/01/		xmlns:wss="http://docs.oasis-open.org/wss/2004/01/
	oasis-200401-wss-wssecurity-secext-1.0"		oasis-200401-wss-wssecurity-secext-1.0"
	xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"		xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
	xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"		xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"
	xmlns:wsp="http://www.w3.org/ns/ws-policy"		xmlns:wsp="http://www.w3.org/ns/ws-policy"
	xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/"		xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/"
	targetNamespace="urn:ietf:params:xml:ns:valid"		targetNamespace="urn:ietf:params:xml:ns:valid"
	elementFormDefault="unqualified"		elementFormDefault="unqualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<xsd:element name="RequestSecurityToken"		<xsd:element name="RequestSecurityToken"
	ref="wst:RequestSecurityTokenType"/>		type="wst:RequestSecurityTokenType"/>
	<xsd:element name="RequestSecurityTokenResponse"		<xsd:element name="RequestSecurityTokenResponse"
	ref="wst:RequestSecurityTokenResponseType"/>		type="wst:RequestSecurityTokenResponseType"/>
	<xsd:element name="OTP" type="xsd:string"/>		<xsd:element name="OTP" type="xsd:string"/>
	<xsd:element name="KeyId" type="xsd:string"/>		<xsd:element name="NextOTP" type="xsd:string"/>
			<xsd:element name="SyncCounter" type="xsd:integer"/>
			<xsd:element name="SyncTime" type="xsd:integer"/>
			<xsd:element name="KeyId" type="pskc:string"/>
			<xsd:element name="DeviceInfo" type="pskc:DeviceInfo"/>
	</xsd:schema>		</xsd:schema>
	</types>		</types>
	<message name="RequestSecurityToken">		<message name="RequestSecurityToken">
	<part name="request" type="valid:RequestSecurityTokenType"/>		<part name="request" element="valid:RequestSecurityToken"/>
	</message>		</message>
	<message name="RequestSecurityTokenResponse">		<message name="RequestSecurityTokenResponse">
	<part name="response" type="valid:RequestSecurityTokenResponseType"/>		<part name="response" element="valid:RequestSecurityTokenResponse"/>
	</message>		</message>
	<portType name="RequestSecurityToken">		<portType name="RequestSecurityToken">
	<operation name="RequestSecurityTokenStart">		<operation name="RequestSecurityTokenStart">
	<input message="RequestSecurityToken"/>		<input message="RequestSecurityToken"/>
	<output message="RequestSecurityTokenResponse"/>		<output message="RequestSecurityTokenResponse"/>
	</operation>		</operation>
	<operation name="RequestSecurityTokenContinue">		<operation name="RequestSecurityTokenContinue">
	<input message="RequestSecurityTokenResponse"/>		<input message="RequestSecurityTokenResponse"/>
	<output message="RequestSecurityTokenResponse"/>		<output message="RequestSecurityTokenResponse"/>
	</operation>		</operation>
	</portType>		</portType>
	<binding name="RequestSecurityTokenBinding">		<binding name="RequestSecurityTokenBinding"
			type="valid:RequestSecurityToken">
	<SOAP:binding style="rpc"		<SOAP:binding style="rpc"
	transport="http://schemas.xmlsoap.org/soap/http"/>		transport="http://schemas.xmlsoap.org/soap/http"/>
	<operation name="RequestSecurityTokenStart">		<operation name="RequestSecurityTokenStart">
	<SOAP:operation style="rpc"/>		<SOAP:operation style="rpc"/>
	<input>		<input>
	<SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>		<SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
	</input>		</input>
	<output>		<output>
	<SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>		<SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
	</output>		</output>
	skipping to change at page 31, line 42 ¶		skipping to change at page 33, line 42 ¶
	http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue		http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
	</wst:RequestType>		</wst:RequestType>
	<wsp:AppliesTo> ... </wsp:AppliesTo> ?		<wsp:AppliesTo> ... </wsp:AppliesTo> ?
	<wsp:Policy> ?		<wsp:Policy> ?
	<saml:Attribute> +		<saml:Attribute> +
	</wsp:Policy>		</wsp:Policy>
	<wst:Lifetime> ... </wst:Lifetime> ?		<wst:Lifetime> ... </wst:Lifetime> ?
	<wss:UsernameToken>		<wss:UsernameToken>
	<wss:Username> ... </wss:Username> ?		<wss:Username> ... </wss:Username> ?
	<valid:KeyId> ... </valid:KeyId> ?		<valid:KeyId> ... </valid:KeyId> ?
			<pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
	<valid:OTP> ... </valid:OTP>		<valid:OTP> ... </valid:OTP>
	</wss:UsernameToken>		</wss:UsernameToken>
	</wst:RequestSecurityToken>		</wst:RequestSecurityToken>
	<wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present,		<wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present,
	the client MUST set the value to the claimed username. The server		the client MUST set the value to the claimed username. The server
	MUST load the corresponding end-user record. Either the <wss:		MUST load the corresponding end-user record. Either the <wss:
	Username> element or the <valid:KeyId> element or both MUST be		Username> element or the <valid:KeyId> element or both MUST be
	present.		present.
	<wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId> If present,		<wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId> If present,
	the client MUST set the value to the OTP token identifier. The		the client MUST set the value to the KeyId of the key used for OTP
	server MUST load the corresponding token record..		computations. The server MUST load the corresponding key record..
			<wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo> If
			present, the client MUST set the subelement values of pskc:
			DeviceInfo as defined in [PSKC] to value that uniuquely identify
			the device used for OTP computations. The server MUST load the
			corresponding device record..
	<wst:RequestSecuityToken/wss:Security/valid:OTP> The client MUST set		<wst:RequestSecuityToken/wss:Security/valid:OTP> The client MUST set
	the value to the OTP value. The server MUST validate the OTP.		the value to the OTP value. The server MUST validate the OTP.
	The server MUST confirm that all the supplied authentication data are		The server MUST confirm that all the supplied authentication data are
	valid for a single end-user.		valid for a single end-user.
	Step 2 - Validation server sends "request security token response"		Step 2 - Validation server sends "request security token response"
	message containing the authentication result to the client.		message containing the authentication result to the client.
	skipping to change at page 32, line 37 ¶		skipping to change at page 34, line 43 ¶
	Name: valid:OTP		Name: valid:OTP
	Type: xsd:string		Type: xsd:string
	Description: The output value of an end-user OTP token		Description: The output value of an end-user OTP token
	Name: valid:KeyId		Name: valid:KeyId
	Type: xsd:string		Type: xsd:string
			Description: The globally-unique identifier for key used in the
			OTP computation
			Name: pskc:DeviceInfo
			Type: pskc:DeviceInfo
			Description: A extensible element to uniquely identify devices
			used in OTP computations as defined in [PSKC].
			B.3. In band one-time-password (OTP) token synchronization
			This section describes the mechanism-specific message contents for
			both time-based, event-based and time-event based OTP algorithms in
			which resynchronization data is sent in-band.
			Synchronization can happen either by sending two subsequqnt OTPs from
			the device or by sending only one OTP and the exact values of one or
			multiple moving factors (e.g.Counter, TIme, etc) used in the OTP
			algorithm.
			There are two steps to the protocol.
			Step 1 - Client sends "request security token" message containing
			synchronization data to the validation server.
			<wst:RequestSecurityToken Context="...">
			<wst:TokenType>
			http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
			</wst:TokenType>
			<wst:RequestType>
			urn:ietf:params:xml:ns:valid#synchronization
			</wst:RequestType>
			<wsp:AppliesTo> ... </wsp:AppliesTo> ?
			<wsp:Policy> ?
			<saml:Attribute> +
			</wsp:Policy>
			<wst:Lifetime> ... </wst:Lifetime> ?
			<wss:UsernameToken>
			<wss:Username> ... </wss:Username> ?
			<valid:KeyId> ... </valid:KeyId> ?
			<pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
			<valid:OTP> ... </valid:OTP>
			<valid:NextOTP> ... </valid:NextOTP>?
			<valid:SyncCounter> ... </valid:SyncCounter>?
			<valid:SyncTimer> ... </valid:SyncTime>?
			</wss:UsernameToken>
			</wst:RequestSecurityToken>
			<wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present,
			the client MUST set the value to the claimed username. The server
			MUST load the corresponding end-user record. Either the <wss:
			Username> element or the <valid:KeyId> element or both MUST be
			present.
			<wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId> If present,
			the client MUST set the value to the KeyId of the key used for OTP
			computations. The server MUST load the corresponding key record..
			<wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo> If
			present, the client MUST set the subelement values of pskc:
			DeviceInfo as defined in [PSKC] to value that uniuquely identify
			the device used for OTP computations. The server MUST load the
			corresponding device record..
			<wst:RequestSecuityToken/wss:Security/valid:OTP> The client MUST set
			the value to the OTP value. The server MUST validate the OTP
			within an extended synchronization window.
			<wst:RequestSecuityToken/wss:Security/valid:NextOTP> If present, the
			client MUST set this value to the next OTP value obtained from the
			OTP device. The server MUST validate this OTP within a normal
			validation window upon successful validation of the first OTP.
			<wst:RequestSecuityToken/wss:Security/valid:SyncCounter> If present,
			the client MUST set the value to the current OTP Counter moving
			factor from the claimed device. The server MUST validate that the
			given OTP corresponds to the given value in <valid:SyncCounter>
			and then set the Counter moving factor value to its own record for
			the claimed token.
			<wst:RequestSecuityToken/wss:Security/valid:SyncTime> If present,
			the client MUST set the value to the current OTP Time moving
			factor from the claimed device. The server MUST validate that the
			given OTP corresponds to the given value in <valid:SyncTime> and
			then set the Time moving factor value to its own record for the
			claimed token.
			The server MUST confirm that all the supplied synchronization data
			are valid and adjust its token record with the validated client data.
			Step 2 - Validation server sends "request security token response"
			message containing the synchronization result to the client.
			<wst:RequestSecurityTokenResponse Context="...">
			<wst:RequestedSecurityToken>
			<saml:Assertion> ... </saml:Assertion>
			</wst:RequestedSecurityToken>
			<wst:Claims> ... </wst:Claims>
			</wst:RequestSecurityTokenResponse>
			The following synchronization data are defined by this specification.
			Name: valid:OTP
			Type: xsd:string
			Description: The output value of an end-user OTP token
			Name: valid:NextOTP
			Type: xsd:string
			Description: The output value of an end-user OTP token for the
			next consecutive OTP
			Name: valid:MovingFactor
			Type: xsd:integer
			Description: The current OTP moving factor in a client token. It
			is the event counter for an event based token, for example, HOTP.
			Name: valid:KeyId
			Type: xsd:string
	Description: The globally-unique identifier for the OTP token		Description: The globally-unique identifier for the OTP token
	B.3. In band challenge/response		B.4. In band challenge/response
	This appendix describes the mechanism-specific message contents for		This appendix describes the mechanism-specific message contents for
	challenge/response authentication mechanisms in which both the		challenge/response authentication mechanisms in which both the
	challenge and response are transferred in-band. Mechanisms of this		challenge and response are transferred in-band. Mechanisms of this
	type include: knowledge-based schemes, matrix card schemes and		type include: knowledge-based schemes, matrix card schemes and
	cryptographic token schemes. There are no semantics implied by the		cryptographic token schemes. There are no semantics implied by the
	order of the elements.		order of the elements.
	There are four steps to the protocol.		There are four steps to the protocol.
	skipping to change at page 33, line 20 ¶		skipping to change at page 38, line 20 ¶
	http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue		http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
	</wst:RequestType>		</wst:RequestType>
	<wsp:AppliesTo> ... </wsp:AppliesTo> ?		<wsp:AppliesTo> ... </wsp:AppliesTo> ?
	<wsp:Policy> ?		<wsp:Policy> ?
	<saml:Attribute> +		<saml:Attribute> +
	</wsp:Policy>		</wsp:Policy>
	<wst:Lifetime> ... </wst:Lifetime> ?		<wst:Lifetime> ... </wst:Lifetime> ?
	<wss:UsernameToken>		<wss:UsernameToken>
	<wss:Username> ... </wss:Username> ?		<wss:Username> ... </wss:Username> ?
	<valid:KeyId> ... </valid:KeyId> ?		<valid:KeyId> ... </valid:KeyId> ?
			<pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
	</wss:UsernameToken>		</wss:UsernameToken>
	</wst:RequestSecurityToken>		</wst:RequestSecurityToken>
	Step 2 - Validation server sends "request security token response"		Step 2 - Validation server sends "request security token response"
	message containing the challenge to the client.		message containing the challenge to the client.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst14:InteractiveChallenge>		<wst14:InteractiveChallenge>
	...		...
	</wst14:InteractiveChallenge>		</wst14:InteractiveChallenge>
	skipping to change at page 34, line 12 ¶		skipping to change at page 39, line 12 ¶
	Step 4 - Server sends "request security token response" message		Step 4 - Server sends "request security token response" message
	containing the authentication result to the client.		containing the authentication result to the client.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>
	<saml:Assertion> ... </saml:Assertion>		<saml:Assertion> ... </saml:Assertion>
	</wst:RequestedSecurityToken>		</wst:RequestedSecurityToken>
	<wst:Claims> ... </wst:Claims>		<wst:Claims> ... </wst:Claims>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	B.4. Out-of-band challenge		B.5. Out-of-band challenge
	This appendix describes the mechanism-specific message contents for		This appendix describes the mechanism-specific message contents for
	challenge/response mechanisms in which the challenge is passed to the		challenge/response mechanisms in which the challenge is passed to the
	end-user out-of-band. Such mechanisms involve a separate		end-user out-of-band. Such mechanisms involve a separate
	communication channel, such as voice telephone, email or SMS. There		communication channel, such as voice telephone, email or SMS. There
	are no semantics implied by the order of the elements.		are no semantics implied by the order of the elements.
	There are four steps to the protocol.		There are four steps to the protocol.
	Step 1 - Client sends "request security token" message containing		Step 1 - Client sends "request security token" message containing
	skipping to change at page 35, line 25 ¶		skipping to change at page 40, line 25 ¶
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>
	<saml:Assertion> ... </saml:Assertion>		<saml:Assertion> ... </saml:Assertion>
	</wst:RequestedSecurityToken>		</wst:RequestedSecurityToken>
	<wst:Claims> ... </wst:Claims>		<wst:Claims> ... </wst:Claims>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST		The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST
	be the same as that used in steps 1, 2 and 3.		be the same as that used in steps 1, 2 and 3.
	B.5. Out-of-band response		B.6. Out-of-band response
	This appendix describes the mechanism-specific message contents for		This appendix describes the mechanism-specific message contents for
	challenge/response mechanisms in which the response is returned to		challenge/response mechanisms in which the response is returned to
	the validation server out-of-band. Such mechanisms involve a		the validation server out-of-band. Such mechanisms involve a
	separate communication channel, such as voice telephone, email or		separate communication channel, such as voice telephone, email or
	SMS. There are no semantics implied by the order of the elements.		SMS. There are no semantics implied by the order of the elements.
	There are four steps to the protocol.		There are four steps to the protocol.
	Step 1 - Client sends "request security token" message containing the		Step 1 - Client sends "request security token" message containing the
	skipping to change at page 36, line 20 ¶		skipping to change at page 41, line 20 ¶
	http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue		http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
	</wst:RequestType>		</wst:RequestType>
	<wsp:AppliesTo> ... </wsp:AppliesTo> ?		<wsp:AppliesTo> ... </wsp:AppliesTo> ?
	<wsp:Policy> ?		<wsp:Policy> ?
	<saml:Attribute> +		<saml:Attribute> +
	</wsp:Policy>		</wsp:Policy>
	<wst:Lifetime> ... </wst:Lifetime> ?		<wst:Lifetime> ... </wst:Lifetime> ?
	<wss:UsernameToken>		<wss:UsernameToken>
	<wss:Username> ... </wss:Username>		<wss:Username> ... </wss:Username>
	<valid:KeyId> ... </valid:KeyId> ?		<valid:KeyId> ... </valid:KeyId> ?
			<pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
	</wss:UsernameToken>		</wss:UsernameToken>
	</wst:RequestSecurityToken>		</wst:RequestSecurityToken>
	Step 2 - Server sends "request security token response" message		Step 2 - Server sends "request security token response" message
	containing the challenge to the client.		containing the challenge to the client.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst14:InteractiveChallenge>		<wst14:InteractiveChallenge>
	...		...
	</wst14:InteractiveChallenge>		</wst14:InteractiveChallenge>
	skipping to change at page 36, line 51 ¶		skipping to change at page 42, line 4 ¶
	Step 4 - Server sends "request security token response" message		Step 4 - Server sends "request security token response" message
	containing the authentication result to the client at the registered		containing the authentication result to the client at the registered
	call-back interface.		call-back interface.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>
	<saml:Assertion> ... </saml:Assertion>		<saml:Assertion> ... </saml:Assertion>
	</wst:RequestedSecurityToken>		</wst:RequestedSecurityToken>
	<wst:Claims> ... </wst:Claims>		<wst:Claims> ... </wst:Claims>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST		The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST
	be the same as that used in steps 1, 2 and 3.		be the same as that used in steps 1, 2 and 3.
	B.6. Client supplies challenge		B.7. Client supplies challenge
	This appendix describes the mechanism-specific message contents for		This appendix describes the mechanism-specific message contents for
	challenge/response mechanisms in which the client supplies the		challenge/response mechanisms in which the client supplies the
	challenge. There are no semantics implied by the order of the		challenge. There are no semantics implied by the order of the
	elements.		elements.
	There are two steps to the protocol.		There are two steps to the protocol.
	Step 1 - Client sends "request security token" message to the		Step 1 - Client sends "request security token" message to the
	validation server, passing both the challenge and the response.		validation server, passing both the challenge and the response.
	skipping to change at page 38, line 4 ¶		skipping to change at page 43, line 10 ¶
	transformed challenge.		transformed challenge.
	Step 2 - Validation server returns "request security token response"		Step 2 - Validation server returns "request security token response"
	message containing the assertion and claims to the client.		message containing the assertion and claims to the client.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst:RequestedSecurityToken>		<wst:RequestedSecurityToken>
	<saml:Assertion> ... </saml:Assertion>		<saml:Assertion> ... </saml:Assertion>
	</wst:RequestedSecurityToken>		</wst:RequestedSecurityToken>
	<wst:Claims> ... </wst:Claims>		<wst:Claims> ... </wst:Claims>
	</wst:RequestSecurityTokenResponse>		</wst:RequestSecurityTokenResponse>
	B.7. Challenge/response with signature		B.8. Challenge/response with signature
	This appendix describes the mechanism-specific message contents for		This appendix describes the mechanism-specific message contents for
	challenge/response authentication mechanisms in which both the		challenge/response authentication mechanisms in which both the
	challenge and response are transferred in-band additionally to other		challenge and response are transferred in-band additionally to other
	parameters that are used in a signature (such as the simmetric		parameters that are used in a signature (such as the simmetric
	signature in [OCRA]. There are no semantics implied by the order of		signature in [OCRA]. There are no semantics implied by the order of
	the elements.		the elements.
	There are four steps to the protocol.		There are four steps to the protocol.
	skipping to change at page 38, line 36 ¶		skipping to change at page 43, line 41 ¶
	http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue		http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
	</wst:RequestType>		</wst:RequestType>
	<wsp:AppliesTo> ... </wsp:AppliesTo> ?		<wsp:AppliesTo> ... </wsp:AppliesTo> ?
	<wsp:Policy> ?		<wsp:Policy> ?
	<saml:Attribute> +		<saml:Attribute> +
	</wsp:Policy>		</wsp:Policy>
	<wst:Lifetime> ... </wst:Lifetime> ?		<wst:Lifetime> ... </wst:Lifetime> ?
	<wss:UsernameToken>		<wss:UsernameToken>
	<wss:Username> ... </wss:Username> ?		<wss:Username> ... </wss:Username> ?
	<valid:KeyId> ... </valid:KeyId> ?		<valid:KeyId> ... </valid:KeyId> ?
			<pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
	</wss:UsernameToken>		</wss:UsernameToken>
	</wst:RequestSecurityToken>		</wst:RequestSecurityToken>
	Step 2 - Validation server sends "request security token response"		Step 2 - Validation server sends "request security token response"
	message containing the set of challenges to the client.		message containing the set of challenges to the client.
	<wst:RequestSecurityTokenResponse Context="...">		<wst:RequestSecurityTokenResponse Context="...">
	<wst14:InteractiveChallenge> +		<wst14:InteractiveChallenge> +
	...		...
	</wst14:InteractiveChallenge>		</wst14:InteractiveChallenge>
	skipping to change at page 41, line 15 ¶		skipping to change at page 46, line 15 ¶
	C.1.3. Challenge/Response Validation - User generated challenge		C.1.3. Challenge/Response Validation - User generated challenge
	An application needs to be able to use a token implementing the OCRA		An application needs to be able to use a token implementing the OCRA
	challenge/response algorithm for identifying the end user. The		challenge/response algorithm for identifying the end user. The
	application generates the challenge to be presented to the token		application generates the challenge to be presented to the token
	(with the end-user keying the challenge into the token by means of a		(with the end-user keying the challenge into the token by means of a
	PINPad) or the challenge presented to the API of the connected token		PINPad) or the challenge presented to the API of the connected token
	The application then uses the protocol to verify the challenge and		The application then uses the protocol to verify the challenge and
	the response from the token.		the response from the token.
	C.1.4. OTP Validation + Server managed PIN		C.1.4. 2-way mutual Challenge/Response Validation
			An application needs to be able to use a token implementing the OCRA
			2 way challenge/response algorithm for identifying the end user and
			the user will identify the validation server. A connected token
			generates a client challenge and trasnmits it to the appllication,
			the application will accept the challenge and send it to the
			validation server, which will then return a server-response to the
			client challenge and a server challenge. The connected token will
			verify the server response and after successfully validating the
			server response sends uses the server-challenge to generate a client-
			response which is sent to the appliaction. The application then uses
			the protocol to verify the the response from the connected client.
			C.1.5. OTP Validation + Server managed PIN
	An application needs to be able to use a token implementing the TOTP		An application needs to be able to use a token implementing the TOTP
	algorithm as one factor and a server managed PIN as a second factor,		algorithm as one factor and a server managed PIN as a second factor,
	for indetifying the end user. The verification of both factors		for indetifying the end user. The verification of both factors
	should occur within one message request/response pair of the		should occur within one message request/response pair of the
	protocol.		protocol.
	C.1.5. MatrixCardValidation - Server generated challenge		C.1.6. MatrixCardValidation - Server generated challenge
	An application needs to be able to use MatrixCard challenge/response		An application needs to be able to use MatrixCard challenge/response
	algorithm for identifying the end user. The application will request		algorithm for identifying the end user. The application will request
	from the validation server the challenge to be presented to the user		from the validation server the challenge to be presented to the user
	via the user interface and the user response entered into a webform		via the user interface and the user response entered into a webform
	The application will then use the protocol to verify the response		The application will then use the protocol to verify the response
	from the token		from the token
	C.2. Synchornisation Use Cases		C.2. Synchronisation Use Cases
	This section describes the use cases relating to synchronisation of		This section describes the use cases relating to synchronisation of
	the token and the server.		the token and the server.
	C.2.1. OTP Token Auto-Resync (NextOTP)		C.2.1. OTP Token Resync with the Next OTPs
	An application needs to validate an OTP. The OTP could not be		An application needs to validate an OTP but the OTP could not be
	validated and the application decides that a re-sync is necessary.		validated because the OTP moving factor is out-of-sync between the
	It uses the next generated OTP from the token in the protocol to re-		token and the server. The validation server detects that the given
	sync the token		OTP corresponds to a future moving factor that falls in an acceptable
			re-sync window. The application decides that a re-sync is necessary.
			It asks the next generated OTP from the token to re-sync the token.
			The validation server adjusts its record of the token's moving factor
			to the one that corresponds to the given OTP upon successful
			validation. Two consecutive OTPs could also be directly used for a
			validation server to re-sync a token, where the server tries to match
			the first OTP with an extended synchronization window and then match
			the second OTP with a normal authentication window.
	C.2.2. OTP Token Manual-resync		C.2.2. OTP Token Resync with Moving Factor
	An application needs to validate an OTP. The OTP could not be		An application needs to validate an OTP but the OTP could not be
	validated and the application decides that a re-sync is necessary.		validated because the OTP moving factor is out-of-sync between the
			token and the server. The validation server detects that the given
			OTP corresponds to a future moving factor that falls in an acceptable
			re-sync window. The application decides that a re-sync is necessary.
	It uses values that can be read by the user of the token (e.g. event		It uses values that can be read by the user of the token (e.g. event
	counter value, time interval counter value) to re-sync the token		counter value, time interval counter value) to re-sync the token
	together with the next generated OTP of the token..		together with the next generated OTP of the token.
	Appendix D. Requirements		Appendix D. Requirements
	This section outlines the most relevant requirements that are the		This section outlines the most relevant requirements that are the
	basis of this work. Several of the requirements were derived from		basis of this work. Several of the requirements were derived from
	use cases described above.		use cases described above.
	R1: The protocol must support authentication of request originator.		R1: The protocol must support authentication of request originator.
	R2: The protocol must support management data flows (e.g., related		R2: The protocol must support management data flows (e.g., related
	skipping to change at page 42, line 32 ¶		skipping to change at page 48, line 32 ¶
	* TOTP		* TOTP
	* Proprietary OTP		* Proprietary OTP
	* Proprietary Challenge/Response		* Proprietary Challenge/Response
	* Matrix cards		* Matrix cards
	* SMS OTP		* SMS OTP
			* PKI based challenge/response
	R4: The protocol must be XML/Web Services based.		R4: The protocol must be XML/Web Services based.
	R5: The protocol must support SOAP intermediaries.		R5: The protocol must support SOAP intermediaries.
	Authors' Addresses		Authors' Addresses
	Philip Hoyer		Philip Hoyer
	ActivIdentity, Inc.		ActivIdentity, Inc.
	117 Waterloo Road		117 Waterloo Road
	London, SE1 8UL		London, SE1 8UL
End of changes. 63 change blocks.
	115 lines changed or deleted		382 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/