< draft-pei-dynamic-symkey-prov-protocol-00.txt		draft-pei-dynamic-symkey-prov-protocol-01.txt >
	Network Working Group M. Pei		Network Working Group M. Pei
	Internet-Draft VeriSign		Internet-Draft VeriSign
	Intended status: Standards Track S. Machani		Intended status: Standards Track S. Machani
	Expires: April 17, 2007 Diversinet		Expires: April 26, 2007 Diversinet
	October 14, 2006		October 23, 2006
	Dynamic Symmetric Key Provisioning Protocol		Dynamic Symmetric Key Provisioning Protocol
	draft-pei-dynamic-symkey-prov-protocol-00.txt		draft-pei-dynamic-symkey-prov-protocol-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 April 17, 2007.		This Internet-Draft will expire on April 26, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document specifies a symmetric key provisioning protocol that		This document specifies a symmetric key provisioning protocol that
	supports provisioning of symmetric keys (One Time Password (OTP) keys		supports provisioning of symmetric keys (One Time Password (OTP) keys
	or symmetric cryptographic keys) and associated attributes		or symmetric cryptographic keys) and associated attributes
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	distributed to the technical community. The authors believe that a		distributed to the technical community. The authors believe that a
	common and shared specification will facilitate adoption of two-		common and shared specification will facilitate adoption of two-
	factor authentication on the Internet by enabling interoperability		factor authentication on the Internet by enabling interoperability
	between commercial and open-source implementations.		between commercial and open-source implementations.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. A mobile device user obtains an HOTP symmetric key		1.2.1. A mobile device user obtains an HOTP symmetric key . . 4
	credential . . . . . . . . . . . . . . . . . . . . . . 4		1.2.2. A user acquires multiple symmetric keys of
	1.2.2. A user acquires multiple credentials of different		different types . . . . . . . . . . . . . . . . . . . 5
	types . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2.3. A key provisioning service imposes a validity
	1.2.3. A credential provisioning service imposes a		period policy for provisioning sessions . . . . . . . 5
	validity period policy for provisioning sessions . . . 5		1.2.4. A symmetric key issuer uses a third party
	1.2.4. A credential issuer uses a third party
	provisioning service provider . . . . . . . . . . . . 5		provisioning service provider . . . . . . . . . . . . 5
	1.2.5. A client application uses a pre-shared transport		1.2.5. A client application uses a pre-shared transport
	key to communicate with provisioning provider . . . . 5		key to communicate with provisioning provider . . . . 5
	1.2.6. A user renews its credential with the same		1.2.6. A user renews its credential with the same
	credential ID . . . . . . . . . . . . . . . . . . . . 6		credential ID . . . . . . . . . . . . . . . . . . . . 6
	1.2.7. An administrator initiates a credential		1.2.7. An administrator initiates a credential
	replacement before it can be used . . . . . . . . . . 6		replacement before it can be used . . . . . . . . . . 6
	1.2.8. A user acquires a credential through SMS . . . . . . . 6		1.2.8. A user acquires a credential through SMS . . . . . . . 6
	1.2.9. A client acquires a credential over a transport		1.2.9. A client acquires a credential over a transport
	protocol that doesn't ensure data confidentiality . . 7		protocol that doesn't ensure data confidentiality . . 7
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 4 ¶
	protocol that doesn't provide authentication . . . . . 7		protocol that doesn't provide authentication . . . . . 7
	1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7		1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	1.4. Good to have requirements . . . . . . . . . . . . . . . . 8		1.4. Good to have requirements . . . . . . . . . . . . . . . . 8
	1.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 8		1.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 8
	2. Notations and Terminology . . . . . . . . . . . . . . . . . . 10		2. Notations and Terminology . . . . . . . . . . . . . . . . . . 10
	2.1. Conventions used in this document . . . . . . . . . . . . 10		2.1. Conventions used in this document . . . . . . . . . . . . 10
	2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 10		2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 10
	2.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 10		2.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 10
	3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Request and Response Messages . . . . . . . . . . . . . . 12		3.1. Request and Response Messages . . . . . . . . . . . . . . 12
	3.2. Symmetric Key Container Format . . . . . . . . . . . . . . 12		3.2. Symmetric Key Container Format . . . . . . . . . . . . . . 13
	3.3. Encryption Key for Credential Response . . . . . . . . . . 12		3.3. Encryption Key for Credential Response . . . . . . . . . . 13
	4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 14		4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.1. Client Authentication . . . . . . . . . . . . . . . . . . 14		4.1. Client Authentication . . . . . . . . . . . . . . . . . . 14
	4.2. Server Authentication . . . . . . . . . . . . . . . . . . 15		4.2. Server Authentication . . . . . . . . . . . . . . . . . . 15
	5. Message Sets . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. SecretContainer . . . . . . . . . . . . . . . . . . . . . 16		5.1. SecretContainer . . . . . . . . . . . . . . . . . . . . . 16
	5.2. CredentialType . . . . . . . . . . . . . . . . . . . . . . 16		5.2. ActivationCode . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. ActivationCode . . . . . . . . . . . . . . . . . . . . . . 16		5.3. AuthenticationDataType . . . . . . . . . . . . . . . . . . 18
	5.4. AuthenticationDataType . . . . . . . . . . . . . . . . . . 19		6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 20
	5.5. GetAuthNonce . . . . . . . . . . . . . . . . . . . . . . . 20		6.1. GetAuthNonce . . . . . . . . . . . . . . . . . . . . . . . 20
	5.6. GetAuthNonceResponse . . . . . . . . . . . . . . . . . . . 21		6.2. GetAuthNonceResponse . . . . . . . . . . . . . . . . . . . 20
	5.7. GetSharedSecret . . . . . . . . . . . . . . . . . . . . . 22		6.3. GetSharedSecret . . . . . . . . . . . . . . . . . . . . . 21
	5.8. GetSharedSecretResponse . . . . . . . . . . . . . . . . . 24		6.4. GetSharedSecretResponse . . . . . . . . . . . . . . . . . 23
	6. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 26		7. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 25
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	7.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 27		8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 26
	7.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 28		8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 27
	7.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 28		8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 27
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 30		10. Normative References . . . . . . . . . . . . . . . . . . . . . 29
	Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 31		Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 30
	Appendix B. Example Requests and Responses . . . . . . . . . . . 39		Appendix B. Example Requests and Responses . . . . . . . . . . . 38
	B.1. Simple client message exchange for acquiring a		B.1. Simple client message exchange for acquiring a
	credential with an activation code . . . . . . . . . . . . 39		credential with an activation code . . . . . . . . . . . . 38
	B.2. Full message exchanges for a client over a non-secure		B.2. Full message exchanges for a client over a non-secure
	channel . . . . . . . . . . . . . . . . . . . . . . . . . 40		channel . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Appendix C. Transport Consideration . . . . . . . . . . . . . . . 43		Appendix C. Transport Consideration . . . . . . . . . . . . . . . 42
	C.1. No security provided in transport layer . . . . . . . . . 43		C.1. No security provided in transport layer . . . . . . . . . 42
	C.2. Confidentiality provided in transport layer . . . . . . . 43		C.2. Confidentiality provided in transport layer . . . . . . . 42
	C.3. Confidentiality and mutual authentication provided in		C.3. Confidentiality and mutual authentication provided in
	transport layer . . . . . . . . . . . . . . . . . . . . . 43		transport layer . . . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 45		Intellectual Property and Copyright Statements . . . . . . . . . . 44
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	This Internet draft describes a standard client-server protocol that		This Internet draft describes a standard client-server protocol that
	enables a client device to download and install authentication		enables a client device to download and install authentication
	credentials from a provisioning server in a secure and efficient		credentials from a provisioning server in a secure and efficient
	manner. The prime example of such an authentication credential is a		manner. The prime example of such an authentication credential is a
	shared secret for One-Time-Password (OTP) software token in a device.		shared secret for One-Time-Password (OTP) software token in a device.
	The protocol is for dynamic provisioning of credentials to a user		The protocol is for dynamic provisioning of shared secret to a user
	device; it is not a bulk provisioning protocol that transfers token		device; it is not a bulk provisioning protocol that transfers token
	records from a provisioning server to an authentication system.		records from a provisioning server to an authentication system.
	This protocol will only support the provisioning of symmetric key		This protocol will only support the provisioning of symmetric secret
	credential types. Asymmetric key pair provisioning isn't the purpose		key types. Asymmetric key pair provisioning isn't the purpose of
	of this protocol. The protocol is a web services XML-based protocol		this protocol. The protocol is a web services XML-based protocol
	with multiple profiles to support lightweight small footprint clients		with multiple profiles to support lightweight small footprint clients
	such as smart cards, as well as more advanced device platforms such		such as smart cards, as well as more advanced device platforms such
	as USB tokens and PDAs/smart phones.		as USB tokens and PDAs/smart phones.
	Existing credential delivery protocols are specific to one		Existing symmetric key delivery protocols are specific to one
	authentication method, or are proprietary to a particular vendor		authentication method, or are proprietary to a particular vendor
	implementation. The industry needs a simple provisioning protocol		implementation. The industry needs a simple provisioning protocol
	standard to enable interoperability across vendors and to provision		standard to enable interoperability across vendors and to provision
	multiple credential types.		multiple shared secret types.
	1.2. Use Cases		1.2. Use Cases
	This section describes a comprehensive list of use cases that		This section describes a comprehensive list of use cases that
	inspired the development of this specification. These requirements		inspired the development of this specification. These requirements
	were used to derive the primary requirement that drove the design.		were used to derive the primary requirement that drove the design.
	These requirements are covered in the next section.		These requirements are covered in the next section.
	In the following, we use word "credential" to mean "symmetric key		In the following, we use words "shared secret" and "credential" to
	credential" when the context is clear.		mean "symmetric key" when the context is clear.
	1.2.1. A mobile device user obtains an HOTP symmetric key credential		1.2.1. A mobile device user obtains an HOTP symmetric key
	A user with a mobile device wants to acquire an HOTP [HOTP]		A user with a mobile device wants to acquire an HOTP [HOTP] secret
	credential (symmetric key) to use with a software token in the		(symmetric key) to use with a software token in the device. The
	device. The credential may be pre-generated by a back end issuance		secret may be pre-generated by a back end issuance server, or
	server, or generated by the provisioning server during the		generated by the provisioning server during the provisioning process.
	provisioning process. A unique Credential ID is assigned to the		A unique Secret ID is assigned to the secret by the provisioning
	credential by the provisioning server. This protocol enables the		server. This protocol enables the client device to request the
	client device to request the credential, authenticate to the		secret, authenticate to the provisioning server, download the secret
	provisioning server, download the credential over-the-air (OTA) and		over-the-air (OTA) and install it on the mobile device.
	install it on the mobile device.
	1.2.2. A user acquires multiple credentials of different types		1.2.2. A user acquires multiple symmetric keys of different types
	A user wants to provision multiple credentials on a device. The		A user wants to provision multiple symmetric keys on a device. The
	credentials may or may not be of the same type. The credentials may		symmetric keys may or may not be of the same type. The keys may be
	be used with different algorithms such as HOTP, symmetric challenge-		used with different algorithms such as HOTP, symmetric challenge-
	response, or others. The protocol must provide for a mechanism to		response, or others. The protocol must provide for a mechanism to
	uniquely identify a specific credential in the device using token		uniquely identify a specific secret in the device using token
	identification to allow device authentication before provisioning.		identification to allow device authentication before provisioning.
	1.2.3. A credential provisioning service imposes a validity period		1.2.3. A key provisioning service imposes a validity period policy for
	policy for provisioning sessions		provisioning sessions
	Once a user initiates a credential request, the credential		Once a user initiates a symmetric key request, the key provisioning
	provisioning service may require that any subsequent actions to		service may require that any subsequent actions to complete the
	complete the provisioning cycle within certain time window. For		provisioning cycle within certain time window. For example, a
	example, a provisioning issuer may provide an authentication code to		provisioning issuer may provide an authentication code to a user upon
	a user upon the user's initial request for a credential. Such an		the user's initial request for a secret key. Such an authentication
	authentication code is associated with a validity period; a user must		code is associated with a validity period; a user must consume the
	consume the pick up code to download a secret within the validity		pick up code to download a secret within the validity window.
	window.
	1.2.4. A credential issuer uses a third party provisioning service		1.2.4. A symmetric key issuer uses a third party provisioning service
	provider		provider
	A credential issuer outsources its credential provisioning to a third		A symmetric key issuer outsources its key provisioning to a third
	party credential provisioning service provider. The issuer is		party key provisioning service provider. The issuer is responsible
	responsible for authenticating and granting rights to users to		for authenticating and granting rights to users to acquire keys while
	acquire credentials while it may delegate the actual credential		it may delegate the actual key generation and provisioning to a third
	generation and provisioning to a third party provisioning service.		party provisioning service. The issuer may acquire secret keys on
	The issuer may acquire credentials on behalf of its users from the		behalf of its users from the provisioning service provider or
	provisioning service provider or redirect the user to acquire the		redirect the user to acquire the secrets directly from provisioning
	credentials directly from provisioning service provider. In the		service provider. In the later case, it is often necessary for a
	later case, it is often necessary for a user to authenticate to the		user to authenticate to the provisioning service provider.
	provisioning service provider.
	1.2.5. A client application uses a pre-shared transport key to		1.2.5. A client application uses a pre-shared transport key to
	communicate with provisioning provider		communicate with provisioning provider
	An HOTP application is loaded to a smart card after the card is		An HOTP application is loaded to a smart card after the card is
	issued. The OTP credential for the HOTP application will then be		issued. The OTP secret for the HOTP application will then be
	provisioned using a secure channel mechanism present in many smart		provisioned using a secure channel mechanism present in many smart
	card platforms. This allows a direct secure channel to be		card platforms. This allows a direct secure channel to be
	established between the smart card chip and the provisioning server.		established between the smart card chip and the provisioning server.
	For example, the card commands (APDU - Application Protocol Data		For example, the card commands (APDU - Application Protocol Data
	Unit) are encrypted with a pre-shared transport key and sent directly		Unit) are encrypted with a pre-shared transport key and sent directly
	to the smart card chip, allowing secure post issuance in-the-field		to the smart card chip, allowing secure post issuance in-the-field
	provisioning. This secure flow can pass SSL and other transport		provisioning. This secure flow can pass SSL and other transport
	security boundaries.		security boundaries.
	This use case requires the protocol to be tunneled and the		This use case requires the protocol to be tunneled and the
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 38 ¶
	SHA1 Secure Hash Algorithm 1		SHA1 Secure Hash Algorithm 1
	SOAP Simple Object Access Protocol		SOAP Simple Object Access Protocol
	XML Extensible Markup Language		XML Extensible Markup Language
	2.3. XML Namespaces		2.3. XML Namespaces
	XML namespace for types defined in this document uses the following:		XML namespace for types defined in this document uses the following:
	xmlns:oath-kp="http://www.openauthentication.org/OATH/2006/10/		xmlns:oath-dskpp="http://www.openauthentication.org/OATH/2006/10/
	DSKPP"		DSKPP"
	The protocol also uses XML types defined in [PSKC] for symmetric key.		The protocol also uses XML types defined in [PSKC] for symmetric key.
	We use the following namespace.		We use the following namespace.
	xmlns:oath-pskc=http://www.openauthentication.org/OATH/2006/08/		xmlns:oath-pskc=http://www.openauthentication.org/OATH/2006/08/
	PSKC		PSKC
	It also uses types in [XMLSIG] for XML signature related types. The		It also uses types in [XMLSIG] for XML signature related types. The
	following namespace is used.		following namespace is used.
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 28 ¶
	not expose any sensitive information over non-secure networks. (2) by		not expose any sensitive information over non-secure networks. (2) by
	the server to mitigate replay attacks.		the server to mitigate replay attacks.
	The second pair of messages, called GetSharedSecret and		The second pair of messages, called GetSharedSecret and
	GetSharedSecretResponse, are the actual credential download messages.		GetSharedSecretResponse, are the actual credential download messages.
	The client request message may include client authentication data,		The client request message may include client authentication data,
	credential type and the client preferences. The server response		credential type and the client preferences. The server response
	message includes the encrypted credential and associated		message includes the encrypted credential and associated
	configuration data.		configuration data.
			|-------------------------------------------------------|
			| |
			| Provisioning Provisioning |
			| Client Server |
			| |
			| | | |
			| |- - - - - GetAuthNonce - - - - - - -> | |
			| | | |
			| |<- - - - GetAuthNonceResponse - - - - | |
			| | | |
			| | | |
			| | | |
			| |-------- GetSharedSecret -----------> | |
			| | | |
			| |<------- GetSharedSecretResponse ---- | |
			| | | |
			| |
			|-------------------------------------------------------|
	The GetAuthNonce is optional in the protocol. When the protocol runs		The GetAuthNonce is optional in the protocol. When the protocol runs
	over a secure transport channel, the GetAuthNonce and		over a secure transport channel, the GetAuthNonce and
	GetAuthNonceResponse message exchange between the client and the		GetAuthNonceResponse message exchange between the client and the
	server may be omitted: The client may initiate the protocol by		server may be omitted: The client may initiate the protocol by
	sending the GetSharedSecret request to the server and the server must		sending the GetSharedSecret request to the server and the server must
	respond with a GetSharedSecretResponse message. When the protocol		respond with a GetSharedSecretResponse message. When the protocol
	runs over a non-secure transport channel, client and server		runs over a non-secure transport channel, client and server
	implementations must support the GetAuthNonce and		implementations must support the GetAuthNonce and
	GetAuthNonceResponse messages: The client must initiate the protocol		GetAuthNonceResponse messages: The client must initiate the protocol
	by sending a GetAuthNonce request to the server and the server must		by sending a GetAuthNonce request to the server and the server must
	skipping to change at page 14, line 27 ¶		skipping to change at page 14, line 27 ¶
	have been authenticated by the server through another mean before		have been authenticated by the server through another mean before
	sending the client request message to the server. For example, a		sending the client request message to the server. For example, a
	provisioning web application for desktop software token may		provisioning web application for desktop software token may
	authenticate the user first, and then accept a provisioning request		authenticate the user first, and then accept a provisioning request
	message; the client application doesn't need to send any		message; the client application doesn't need to send any
	authentication data inside the credential request message.		authentication data inside the credential request message.
	When authentication data is required in the client request, such data		When authentication data is required in the client request, such data
	is typically a device certificate or an one time use authentication		is typically a device certificate or an one time use authentication
	code, called activation code, acquired out of band by the device user		code, called activation code, acquired out of band by the device user
	owner from the credential issuer.		owner from the credential issuer. The following diagram indicates
			relationships among related entities.
			------------ Get Activation Code ------------
			| User |----------------------->| Issuer |
			------------ ------------
			| |
			| |
			| |
			V V
			-------------- --------------
			| Provisioning | | Provisioning |
			| Client |<------------------->| Server |
			-------------- --------------
	Considering an activation code as a special form of shared secret		Considering an activation code as a special form of shared secret
	between a user and a provisioning service, the authentication data		between a user and a provisioning service, the authentication data
	can have one of the following three forms:		can have one of the following three forms:
	- AuthenticationData = HASH (activation code)		- AuthenticationData = HASH (activation code)
	- AuthenticationData = HMAC (activation code, serverNonce)		- AuthenticationData = HMAC (activation code, serverNonce)
	- AuthenticationData = <Signed data with a client certificate>		- AuthenticationData = <Signed data with a client certificate>
	When an activation code is used to initiate the provisioning session,		When an activation code is used to initiate the provisioning session,
	the activation code must be sent to the provisioning server in a		the activation code must be sent to the provisioning server in a
	secure way. If the underlying transport channel is secure, the		secure way. If the underlying transport channel is secure, the
	authentication data may contain the plaintext format or the hashed		authentication data may contain the plaintext format or the hashed
	format of the activation code using a hash function as follows:		format of the activation code using a hash function as follows:
	AuthenticationData = HASH (activation code)		AuthenticationData = HASH (activation code)
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	transport layer server authentication if it is available.		transport layer server authentication if it is available.
	Symmetric key container response is typically encrypted with a shared		Symmetric key container response is typically encrypted with a shared
	secret. A client can authenticate the service by verification of the		secret. A client can authenticate the service by verification of the
	correct response encryption with expected encryption key.		correct response encryption with expected encryption key.
	In the case where a device certificate is used for authentication,		In the case where a device certificate is used for authentication,
	server authentication by underlying transport layer should be used		server authentication by underlying transport layer should be used
	between the client and the provisioning service.		between the client and the provisioning service.
	5. Message Sets		5. Data Types
	5.1. SecretContainer		5.1. SecretContainer
	This represents the default symmetric key container in a response		This represents the default symmetric key container in a response
	uses <SecretContainerType> define in XML schema namespace "oath-pskc"		uses <SecretContainerType> define in XML schema namespace "oath-pskc"
	by [PSKC].		by [PSKC].
	5.2. CredentialType		5.2. ActivationCode
	CredentialType defines the symmetric key container in a response. It
	uses PSKC <SecretContainer> by default but also allows other format
	such as PKCS12.
	The CredentialType is defined as follows:
	<complexType name="CredentialType">
	<choice>
	<element name="SecretContainer"
	type="oath-pskc:SecretContainerType"/>
	<any namespace="##other" processContents="strict"/>
	</choice>
	<attribute name="format" type="oath-kp:CredentialFormatType"
	default="PSKC"/>
	</complexType>
	The components of the CredentialType have the following meanings:
	o <SecretContainer> indicates the PSKC secret container. It should
	be used when the value of <format> attribute is "PSKC".
	o <format> attribute indicates one of supported credential container
	format.
	o <any> is used to represent the other format of credential
	container type when the value of <format> attribute isn't "PSKC".
	5.3. ActivationCode
	Activation code represents a one time use authentication code given		Activation code represents a one time use authentication code given
	by the issuer to the user to acquire a credential.		by the issuer to the user to acquire a credential.
	An activation code may or may not contain alpha letters in addition		An activation code may or may not contain alpha letters in addition
	to numerical digits depending on the device type and issuer policy.		to numerical digits depending on the device type and issuer policy.
	For a mobile phone, it is often a good practice that only numerical		For a mobile phone, it is often a good practice that only numerical
	digits are used for easy to input.		digits are used for easy to input.
	An activation code can be sent to the provisioning server in (1)		An activation code can be sent to the provisioning server in (1)
	skipping to change at page 17, line 39 ¶		skipping to change at page 17, line 13 ¶
	The ActivationCodeDigestType is defined as follows:		The ActivationCodeDigestType is defined as follows:
	<complexType name="ActivationCodeDigestType">		<complexType name="ActivationCodeDigestType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Includes a digest of activation code.		Includes a digest of activation code.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<simpleContent>		<simpleContent>
	<extension base="base64Binary">		<extension base="base64Binary">
	<attribute name="algorithm" type="oath-kp:DigestAlgorithmType"		<attribute name="algorithm" type="oath-pskc:HashAlgorithmType"
	use="required"/>		use="required"/>
	</extension>		</extension>
	</simpleContent>		</simpleContent>
	</complexType>		</complexType>
	The components of the ActivationCodeDigestType have the following		The components of the ActivationCodeDigestType have the following
	meanings:		meanings:
	o <algorithm> attribute indicates one of supported message digest		o <algorithm> attribute indicates one of supported message digest
	methods. By default, it can use SHA1 with identifier		methods. <HashAlgorithmType> is defined in [PSKC].
	"http://www.w3.org/2000/09/xmldsig#sha1"
	The other choices are
	"http://www.w3.org/2001/04/xmldsig-more#sha256"
	"http://www.w3.org/2001/04/xmldsig-more#sha512"
	The ActivationCodeMacType is defined as follows:		The ActivationCodeMacType is defined as follows:
	<complexType name="ActivationCodeMacType">		<complexType name="ActivationCodeMacType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Includes a HMAC of activation code with nonce as key.		Includes a HMAC of activation code with nonce as key.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<sequence>		<sequence>
	<element name="Data" type="base64Binary"/>		<element name="Data" type="base64Binary"/>
	<element name="Nonce" type="oath-kp:NonceType" minOccurs="0"/>		<element name="Nonce" type="oath-dskpp:NonceType" minOccurs="0"/>
	</sequence>		</sequence>
	<attribute name="algorithm" type="oath-kp:CredentialIdType"		<attribute name="algorithm" type="oath-pskc:DigestAlgorithmType"
	use="required"/>		use="required"/>
	<attribute name="nonceId" type="oath-kp:IdentifierType"		<attribute name="nonceId" type="oath-dskpp:IdentifierType"/>
	use="optional"/>		</complexType>
	</complexType>
	The components of the ActivationCodeMacType have the following		The components of the ActivationCodeMacType have the following
	meanings:		meanings:
	o <Data> carries the HMAC authentication data derived from		o <Data> carries the HMAC authentication data derived from
	activation code and nonce value.		activation code and nonce value.
	o <Nonce> contains a nonce value. The value is acquired through a		o <Nonce> contains a nonce value. The value is acquired through a
	request <GetAuthNonce> to the server. The <Nonce> element can be		request <GetAuthNonce> to the server. The <Nonce> element can be
	omitted		omitted
	o <algorithm> attribute indicates one of supported MAC algorithms.		o <algorithm> attribute indicates one of supported MAC algorithms.
	By default, it can use HMAC-SHA1 with identifier		<DigestAlgorithmType> is defined in [PSKC].
	"http://www.w3.org/2000/09/xmldsig#hmac-sha1"
	The other choices are
	"http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"
	"hhttp://www.w3.org/2001/04/xmldsig-more#hmac-sha512"
	o <nonceId> should have the value of <sessionId> returned in a		o <nonceId> should have the value of <sessionId> returned in a
	response message <GetAuthNonceResponse> if it is used.		response message <GetAuthNonceResponse> if it is used.
	5.4. AuthenticationDataType		5.3. AuthenticationDataType
	AuthenticationDataType represents a client's authentication data sent		AuthenticationDataType represents a client's authentication data sent
	to a provisioning server. It is optional element in a request		to a provisioning server. It is optional element in a request
	message when out of band authentication is done outside of		message when out of band authentication is done outside of
	provisioning process.		provisioning process.
	The AuthenticationDataType is defined as follows:		The AuthenticationDataType is defined as follows:
	<complexType name="AuthenticationDataType">		<complexType name="AuthenticationDataType">
	<sequence>		<sequence>
	<element name="ClientId" type="anyURI" minOccurs="0"/>		<element name="ClientId" type="anyURI" minOccurs="0"/>
	<choice minOccurs="0">		<choice minOccurs="0">
	<element name="ActivationCode"		<element name="ActivationCode"
	type="oath-kp:ActivationCodeType"/>		type="oath-dskpp:ActivationCodeType"/>
	<element name="ActivationCodeDigest"		<element name="ActivationCodeDigest"
	type="oath-kp:ActivationCodeDigestType"/>		type="oath-dskpp:ActivationCodeDigestType"/>
	<element name="ActivationCodeMac"		<element name="ActivationCodeMac"
	type="oath-kp:ActivationCodeMacType"/>		type="oath-dskpp:ActivationCodeMacType"/>
	<any namespace="##other" processContents="strict"/>		<any namespace="##other" processContents="strict"/>
	</choice>		</choice>
	</sequence>		</sequence>
	<attribute name="form" type="oath-kp:AuthDataFormType"		<attribute name="form" type="oath-dskpp:AuthDataFormType"
	default="ACTIVATIONCODE"/>		default="ACTIVATIONCODE"/>
	</complexType>		</complexType>
	<simpleType name="AuthDataFormType">		<simpleType name="AuthDataFormType">
	<restriction base="string">		<restriction base="string">
	<enumeration value="ACTIVATIONCODE"/>		<enumeration value="ACTIVATIONCODE"/>
	<enumeration value="CERTIFICATE"/>		<enumeration value="CERTIFICATE"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	skipping to change at page 20, line 23 ¶		skipping to change at page 19, line 24 ¶
	o <ActivationCodeMac> is used when an activation code is used along		o <ActivationCodeMac> is used when an activation code is used along
	with a server nonce to produce authentication data value.		with a server nonce to produce authentication data value.
	o <any> represents other form of authentication data not defined		o <any> represents other form of authentication data not defined
	here. It can be XML signed data defined by [XMLSIG] when a client		here. It can be XML signed data defined by [XMLSIG] when a client
	certificate is used to act authentication credential.		certificate is used to act authentication credential.
	o <form> attribute indicates the authentication credential value		o <form> attribute indicates the authentication credential value
	form type <AuthDataFormType>. When this attribute has value		form type <AuthDataFormType>. When this attribute has value
	"ACTIVATIONCODE", the the data can be any one of the three		"ACTIVATIONCODE", the data can be any one of the three activation
	activation code related types. If the attribute has value		code related types. If the attribute has value "CERTIFICATE", the
	"CERTIFICATE", the authentication data value will be a certificate		authentication data value will be a certificate signed data; it
	signed data; it should use the <any> choice to carry the value.		may use the <any> choice to carry the value, or the XML signature
			element according to XML signature specification [XMLSIG] for the
			request.
	5.5. GetAuthNonce		6. Protocol Messages
			6.1. GetAuthNonce
	GetAuthNonce with GetAuthNonceType represents a request to acquire a		GetAuthNonce with GetAuthNonceType represents a request to acquire a
	server nonce value. It is often used when a client needs to securely		server nonce value. It is often used when a client needs to securely
	send user authentication data to a server.		send user authentication data to a server.
	The GetAuthNonceType is defined as follows:		The GetAuthNonceType is defined as follows:
	<element name="GetAuthNonce" type="oath-kp:GetAuthNonceType"/>		<element name="GetAuthNonce" type="oath-dskpp:GetAuthNonceType"/>
	<complexType name="GetAuthNonceType">		<complexType name="GetAuthNonceType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:RequestAbstractType">		<extension base="oath-dskpp:RequestAbstractType">
	<sequence>		<sequence>
	<element name="ClientId"		<element name="ClientId" type="anyURI"/>
	type="anyURI"/>		</sequence>
	</sequence>		</extension>
	</extension>		</complexContent>
	</complexContent>
	</complexType>		</complexType>
	The components of the GetAuthNonceType have the following meanings:		The components of the GetAuthNonceType have the following meanings:
	o <ClientId>, a unique identifier associated with the requestor's		o <ClientId>, a unique identifier associated with the requestor's
	activation code. This identifier must also be used in the		activation code. This identifier must also be used in the
	subsequent authentication data element <AuthenticationData> that		subsequent authentication data element <AuthenticationData> that
	uses <ActivationCodeMac> when it is submitted to download a		uses <ActivationCodeMac> when it is submitted to download a
	credential with <GetSharedSecret>		credential with <GetSharedSecret>
	o <version> attribute, inherited from <RequestAbstractType>, is the		o <version> attribute, inherited from <RequestAbstractType>, is the
	message version used in the client.		message version used in the client.
	o <id> attribute, inherited from <RequestAbstractType>, is a unique		o <requestId> attribute, inherited from <RequestAbstractType>, is a
	identifier to track this request.		unique identifier to track this request.
	5.6. GetAuthNonceResponse		6.2. GetAuthNonceResponse
	GetAuthNonceReponse with GetAuthNonceResponseType represents a		GetAuthNonceReponse with GetAuthNonceResponseType represents a
	response to a request of type GetAuthNonceType. It can optionally		response to a request of type GetAuthNonceType. It can optionally
	return credential ID for the credential to issue, and service ID for		return secret ID for the secret to issue, and service ID for service
	service information		information
	The GetAuthNonceResponseType is defined as follows:		The GetAuthNonceResponseType is defined as follows:
	<complexType name="GetAuthNonceResponseType">		<complexType name="GetAuthNonceResponseType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:ResponseAbstractType">		<extension base="oath-dskpp:ResponseAbstractType">
	<sequence minOccurs="0" maxOccurs="unbounded">		<sequence minOccurs="0" maxOccurs="unbounded">
	<element name="CredentialId"		<element name="SecretId" type="string"/>
	type="oath-kp:CredentialIdType"/>		<element name="ServiceId" type="oath-dskpp:IdentifierType"/>
	<element name="ServiceId" type="oath-kp:IdentifierType"/>		</sequence>
	</sequence>		<attribute name="serverNonce" type="oath-dskpp:NonceType"
	<attribute name="serverNonce" type="oath-kp:NonceType"/>		use="required"/>
	<attribute name="sessionId" type="oath-kp:IdentifierType"		<attribute name="sessionId" type="oath-dskpp:IdentifierType"/>
	use="optional"/>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>
	The components of the GetAuthNonceResponseType have the following		The components of the GetAuthNonceResponseType have the following
	meanings:		meanings:
	o <CredentialId> contains server assigned credential ID		o <SecretId> contains server assigned secret ID
	o <ServiceId> indicates service information.		o <ServiceId> indicates service information.
	o <serverNonce> is a pseudorandom string generated by the		o <serverNonce> is a pseudorandom string generated by the
	provisioning server. It will be used along with activation code		provisioning server. It will be used along with activation code
	to construct authentication token to acquire a credential.		to construct authentication token to acquire a credential.
	o <sessionId> is a server generated ID for this request. The server		o <sessionId> is a server generated ID for this request. The server
	typically accepts the request ID from the request and won't		typically accepts the request ID from the request and won't
	generate a new ID. This allows a server to choose its own session		generate a new ID. This allows a server to choose its own session
	ID to identify a request.		ID to identify a request.
	o <requestId> attribute, inherited from <ResponseAbstractType>, is		o <requestId> attribute, inherited from <ResponseAbstractType>, is
	the ID that the corresponding request sent.		the ID that the corresponding request sent.
	o <version> attribute, inherited from <ResponseAbstractType>, is the		o <version> attribute, inherited from <ResponseAbstractType>, is the
	message version used in the response.		message version used in the response.
	5.7. GetSharedSecret		6.3. GetSharedSecret
	GetSharedRequest is the main request message to request a credential		GetSharedRequest is the main request message to request a secret
	by a client to a provisioning server. It is defined by the type		(symmetric key credential) by a client to a provisioning server. It
	GetSharedSecretType.		is defined by the type GetSharedSecretType.
	The GetSharedSecret is defined as follows:		The GetSharedSecret is defined as follows:
	<element name="GetSharedSecret" type="oath-kp:GetSharedSecretType"/>		<element name="GetSharedSecret" type="oath-dskpp:GetSharedSecretType"/>
	<complexType name="GetSharedSecretType">		<complexType name="GetSharedSecretType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:RequestAbstractType">		<extension base="oath-dskpp:RequestAbstractType">
	<sequence maxOccurs="unbounded">		<sequence maxOccurs="unbounded">
	<element name="CredentialId"		<element name="SecretId"
	type="oath-kp:CredentialIdType" minOccurs="0"/>		type="string" minOccurs="0"/>
	<element name="ClientType" type="oath-kp:ClientTypeType"		<element name="ClientForm" type="oath-dskpp:ClientFormType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="DeviceId" type="oath-pskc:DeviceIdType"		<element name="DeviceId" type="oath-pskc:DeviceIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="AuthenticationData"		<element name="AuthenticationData"
	type="oath-kp:AuthenticationDataType" minOccurs="0"/>		type="oath-dskpp:AuthenticationDataType"
	<element name="SecretAlgorithm"		minOccurs="0"/>
	type="oath-pskc:SecretAlgorithmType"		<element name="SecretAlgorithm"
	minOccurs="0"/>		type="oath-pskc:SecretAlgorithmType"
	<element name="OtpAlgorithm"		minOccurs="0"/>
	type="oath-pskc:OtpAlgorithmIdentifierType"		<element name="Usage"
	minOccurs="0"/>		type="oath-pskc:UsageType"
	<element name="SharedSecretDeliveryMethod"		minOccurs="0"/>
	type="oath-kp:SharedSecretDeliveryMethodType"		<element name="SharedSecretDeliveryMethod"
	minOccurs="0"/>		type="oath-dskpp:SharedSecretDeliveryMethodType"
	<element name="SupportedEncryptionAlgorithm"		minOccurs="0"/>
	type="oath-pskc:EncryptionAlgorithmType"		<element name="SupportedEncryptionAlgorithm"
	minOccurs="0"/>		type="oath-pskc:EncryptionAlgorithmType"
	<element name="LogoPreference"		minOccurs="0"/>
	type="oath-logo:LogoImageInfoType" minOccurs="0"/>		<element name="LogoPreference"
	<element name="Extension" type="oath-kp:ExtensionType"		type="oath-logo:LogoImageInfoType" minOccurs="0"/>
	minOccurs="0" maxOccurs="unbounded"/>		<element name="Extension" type="oath-dskpp:ExtensionType"
	</sequence>		minOccurs="0" maxOccurs="unbounded"/>
	</extension>		</sequence>
	</complexContent>		</extension>
	</complexType>		</complexContent>
			</complexType>
	The components of the GetSharedSecretType have the following		The components of the GetSharedSecretType have the following
	meanings:		meanings:
	o <CredentialId> can be either client supplied or server assigned.		o <SecretId> can be either client supplied or server assigned. If a
	If a Credential ID isn't given in a request, the server will		SecretId isn't given in a request, the server will assign one in
	assign one in its response to such a request. If a server returns		its response to such a request. If a server returns an existing
	an existing credential ID in a device, the client should replace		secret ID in a device, the client should replace the secret.
	the credential.
	o <ClientType> indicates the device type.		o <ClientForm> indicates the device type.
	o <DeviceId> conveys the device information. It is defined in OATH		o <DeviceId> conveys the device information. It is defined in OATH
	[PSKC] specification.		[PSKC] specification.
	o <AuthenticationData> carries authentication data that can be a		o <AuthenticationData> carries authentication data that can be a
	pre-acquired authentication credential by the user for the service		pre-acquired authentication credential by the user for the service
	authorization, a server nonce mixed hash data, or device		authorization, a server nonce mixed hash data, or device
	certificate signed data.		certificate signed data.
	o <SecretAlgorithm> indicates the requested type of symmetric key		o <SecretAlgorithm> indicates the requested type of symmetric key
	credential type.		credential type.
	o <OtpAlgorithm> indicates the OTP algorithm supported by the token		o <Usage> indicates the usage of the HOTP secret supported by the
	device. It is used when the requested SecretAlgorithm is HOTP.		token device. It is used when the requested SecretAlgorithm is
			HOTP.
	o <SharedSecretDeliveryMethod> specifies the mechanism to be used		o <SharedSecretDeliveryMethod> specifies the mechanism to be used
	for delivering the shared-secret e.g. via HTTPS or SMS . For		for delivering the shared-secret e.g. via HTTPS or SMS . For
	example, a request may be initiated from a desktop environment,		example, a request may be initiated from a desktop environment,
	and asks the server to send the secret to a cell phone through SMS		and asks the server to send the secret to a cell phone through SMS
	for those phones that doesn't support internet access.		for those phones that doesn't support internet access.
	o <SupportedEncryptionAlgorithm> indicates the algorithm that the		o <SupportedEncryptionAlgorithm> indicates the algorithm that the
	service should use to encrypt the shared-secret. The inherited		service should use to encrypt the shared-secret. The inherited
	optional element Signature may contain the signature over the		optional element Signature may contain the signature over the
	entire request document depending upon the capabilities of the		entire request document depending upon the capabilities of the
	device and the presence of a device certificate.		device and the presence of a device certificate.
	o <LogoPreference> describes preferred logo that the issuer should		o <LogoPreference> describes preferred logo that the issuer should
	return.		return.
	o <Extension> allows additional request information.		o <Extension> allows additional request information.
	o <id> attribute is inherited from <RequestAbstractType>. There is		o <requestId> attribute is inherited from <RequestAbstractType>.
	also <version> inherited. They indicate respectively the client		There is also <version> inherited. They indicate respectively the
	protocol version and a unique identifier to track this request.		client protocol version and a unique identifier to track this
			request.
	5.8. GetSharedSecretResponse		6.4. GetSharedSecretResponse
	The GetSharedSecretResponse element represents a provisioning service		The GetSharedSecretResponse element represents a provisioning service
	response message corresponding to a shared secret request. Such a		response message corresponding to a shared secret request. Such a
	message contains shared secret container similarly defined by OATH		message contains shared secret container defined by OATH [PSKC] by
	[PSKC] and a field that specifies the mechanism being used for		default and a field that specifies the mechanism being used for
	delivering the shared-secret e.g. via HTTPS or SMS. Either the user		delivering the shared-secret e.g. via HTTPS or SMS. Either the user
	Activation Code derived key or public key of a device certificate can		Activation Code derived key or public key of a device certificate can
	act as the encryption key in SecretContainer to encrypt the secret.		act as the encryption key in SecretContainer to encrypt the secret.
	The GetSharedSecretResponse is defined as follows:		The GetSharedSecretResponse is defined as follows:
	<element name="GetSharedSecretResponse"		<element name="GetSharedSecretResponse"
	type="oath-kp:GetSharedSecretResponseType"/>		type="oath-dskpp:GetSharedSecretResponseType"/>
	<complexType name="GetSharedSecretResponseType">		<complexType name="GetSharedSecretResponseType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:ResponseAbstractType">		<extension base="oath-dskpp:ResponseAbstractType">
	<sequence minOccurs="0">		<sequence minOccurs="0">
	<element name="SharedSecretDeliveryMethod"		<element name="SharedSecretDeliveryMethod"
	type="oath-kp:SharedSecretDeliveryMethodType"		type="oath-dskpp:SharedSecretDeliveryMethodType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="Credential" type="oath-kp:CredentialType"		<choice>
	minOccurs="0"/>		<element name="SecretContainer"
	<element name="Extension" type="oath-kp:ExtensionType"		type="oath-pskc:SecretContainerType"/>
	minOccurs="0" maxOccurs="unbounded"/>		<any namespace="##other" processContents="strict"/>
	</sequence>		</choice>
	</extension>		<element name="Extension" type="oath-dskpp:ExtensionType"
	</complexContent>		minOccurs="0" maxOccurs="unbounded"/>
	</complexType>		</sequence>
			<attribute name="format"
			type="oath-dskpp:SecretContainerFormatType" default="PSKC"/>
			</extension>
			</complexContent>
			</complexType>
	The components of the GetSharedSecretResponseType have the following		The components of the GetSharedSecretResponseType have the following
	meanings:		meanings:
	o <SharedSecretDeliveryMethod> specifies the shared secret delivery		o <SharedSecretDeliveryMethod> specifies the shared secret delivery
	method. The value can be HTTP, HTTPS or SMS.		method. The value can be HTTP, HTTPS or SMS.
	o <Credential> contains credential related information. It can be		o <SecretContainer> indicates the PSKC secret container. It should
	one or many credentials. The default format of credential is		be used when the value of <format> attribute is "PSKC".
	PSKC. Other credential format such as PKCS12 can also be used by
	a provisioning server.		o <any> is used to represent the other format of credential
			container type when the value of <format> attribute isn't "PSKC".
	o <Extension> allows a server to return additional information. A		o <Extension> allows a server to return additional information. A
	provisioning service provider may specify its own extensions.		provisioning service provider may specify its own extensions.
	6. Protocol Binding		o <format> attribute indicates one of supported credential container
			format. The default format of credential is PSKC. Other
			credential format such as PKCS12 can also be used by a
			provisioning server.
			7. Protocol Binding
	The provisioning messages can support HTTP and SOAP binding to enable		The provisioning messages can support HTTP and SOAP binding to enable
	web service support.		web service support.
	For HTTP binding, the requests can be simply posted with HTTP header		For HTTP binding, the requests can be simply posted with HTTP header
	application/xml. The server parses message content to determine the		application/xml. The server parses message content to determine the
	request type. SOAP binding uses standard SOAP header. The protocol		request type. SOAP binding uses standard SOAP header. The protocol
	doesn't require special headers.		doesn't require special headers.
	7. Security Considerations		8. Security Considerations
	The protocol messages contain sensitive information such as user		The protocol messages contain sensitive information such as user
	authentication data and symmetric keys that are transported between a		authentication data and symmetric keys that are transported between a
	provisioning service provider and end user device. The protocol has		provisioning service provider and end user device. The protocol has
	defined mechanisms to protect the messages for confidentiality,		defined mechanisms to protect the messages for confidentiality,
	authenticity, and integrity. An implementation must pay attention to		authenticity, and integrity. An implementation must pay attention to
	the different choices and their strengths according to standard		the different choices and their strengths according to standard
	security best practices, in particular, when data is sent over non-		security best practices, in particular, when data is sent over non-
	secure channel.		secure channel.
	7.1. Authentication		8.1. Authentication
	Mutual authentication MUST be used between a client and the		Mutual authentication MUST be used between a client and the
	provisioning service. A service provider should authenticate a		provisioning service. A service provider should authenticate a
	client to ensure that an issued credential is delivered to the		client to ensure that an issued credential is delivered to the
	intended device.		intended device.
	When a device certificate is used for client authentication, the		When a device certificate is used for client authentication, the
	provisioning server should follow standard certificate verification		provisioning server should follow standard certificate verification
	processes to ensure that it is a trusted device.		processes to ensure that it is a trusted device.
	skipping to change at page 28, line 5 ¶		skipping to change at page 27, line 5 ¶
	nonce value is almost public across a non-secure channel, the key		nonce value is almost public across a non-secure channel, the key
	strength lies in the activation code. The activation code length		strength lies in the activation code. The activation code length
	used with a non-secure channel should be longer than what is used		used with a non-secure channel should be longer than what is used
	over a secure channel. When a device cannot handle a long activation		over a secure channel. When a device cannot handle a long activation
	code in a user friendly manner such as some mobile phones with small		code in a user friendly manner such as some mobile phones with small
	screens, it is necessary to use only the secure channel to		screens, it is necessary to use only the secure channel to
	communicate with a provisioning service.		communicate with a provisioning service.
	See section Section 4.2		See section Section 4.2
	7.2. Confidentiality		8.2. Confidentiality
	The credential payload is encrypted by either a client's public key		The credential payload is encrypted by either a client's public key
	or a key derived from a mutual secret (activation code or pre-		or a key derived from a mutual secret (activation code or pre-
	generated key) between a user and the service. When data is sent		generated key) between a user and the service. When data is sent
	over a non-secure channel, the encryption key may be subject to brute		over a non-secure channel, the encryption key may be subject to brute
	force attack if the underlying key material isn't properly chosen.		force attack if the underlying key material isn't properly chosen.
	In addition to strong activation code choice, the service should		In addition to strong activation code choice, the service should
	follow standard practice in adopting the proper encryption algorithm.		follow standard practice in adopting the proper encryption algorithm.
	7.3. Integrity		8.3. Integrity
	The provisioning request message has an optional signature element to		The provisioning request message has an optional signature element to
	ensure the integrity of message and the request. In an environment		ensure the integrity of message and the request. In an environment
	where credentials are tracked according to device IDs and there is no		where credentials are tracked according to device IDs and there is no
	binding relationship between a device ID and authentication data		binding relationship between a device ID and authentication data
	(e.g., Activation Code), it is recommended that the use of a digital		(e.g., Activation Code), it is recommended that the use of a digital
	signature is enforced to prevent a user from binding a credential to		signature is enforced to prevent a user from binding a credential to
	another user device.		another user device.
	8. Acknowledgements		9. Acknowledgements
	The use cases and requirements are extended from early list created		The use cases and requirements are extended from early list created
	by OATH [OATH] provisioning work group. The protocol is developed		by OATH [OATH] provisioning work group. The protocol is developed
	from some work contributed to OATH [OATH] from its members. The		from some work contributed to OATH [OATH] from its members. The
	authors would like to thank the following people for their		authors would like to thank the following people for their
	contribution during use case developing, protocol conception and		contribution during use case developing, protocol conception and
	review: Stu Vaeth (Diversinet), Salil Sane (VeriSign), Panna		review: Stu Vaeth (Diversinet), Salil Sane (VeriSign), Panna
	Chowdhury (VeriSign), Shuh Chang (Gemalto), Kevin Lewis (SanDisk),		Chowdhury (VeriSign), Shuh Chang (Gemalto), Kevin Lewis (SanDisk),
	Jim Spring (Ironkey), Phillip Hallam-Baker (VeriSign), Philip Hoyer		Jim Spring (Ironkey), Phillip Hallam-Baker (VeriSign), Philip Hoyer
	(ActiveIdentity), Siddharth Bajaj (VeriSign), Susan Cannon (SanDisk),		(ActiveIdentity), Siddharth Bajaj (VeriSign), Susan Cannon (SanDisk),
	Jon Martinsson (Portwise), Jeffrey Bohren (BMC), Ron LaPedis		Jon Martinsson (Portwise), Jeffrey Bohren (BMC), Ron LaPedis
	(SanDisk) and Robert Zuccherato (Entrust).		(SanDisk) and Robert Zuccherato (Entrust).
	9. Normative References		10. Normative References
	[HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password		[HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
	Algorithm", RFC 4226,		Algorithm", RFC 4226,
	URL: http://rfc.sunsite.dk/rfc/rfc4226.html,		URL: http://rfc.sunsite.dk/rfc/rfc4226.html,
	December 2005.		December 2005.
	[OATH] "Initiative for Open AuTHentication",		[OATH] "Initiative for Open AuTHentication",
	URL: http://www.openauthentication.org.		URL: http://www.openauthentication.org.
	[OATHRefArch]
	OATH, "Reference Architecture",
	URL: http://www.openauthentication.org, Version 1.0, 2005.
	[PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange		[PKCS12] RSA Laboratories, "PKCS #12: Personal Information Exchange
	Syntax Standard", Version 1.0,		Syntax Standard", Version 1.0,
	URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.		URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/.
	[PKCS5] RSA Laboratories, "PKCS #5: Password-Based Cryptography
	Standard", Version 2.0,
	URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5/,
	March 1999.
	[PKCS5XML]		[PKCS5XML]
	RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",		RSA Laboratories, "XML Schema for PKCS #5 Version 2.0",
	Version PKCS#5 2.0 Amd.1, URL: ftp://ftp.rsasecurity.com/		Version PKCS#5 2.0 Amd.1, URL: ftp://ftp.rsasecurity.com/
	pub/pkcs/pkcs-5v2/pkcs-5v2-0a1d2.pdf, October 2006.		pub/pkcs/pkcs-5v2/pkcs-5v2-0a1d2.pdf, October 2006.
	[PSKC] Vassilev, A., "Portable Symmetric Key Container",		[PSKC] Vassilev, A., "Portable Symmetric Key Container",
	RFC Draft, Version 1.1, URL: http://www.ietf.org/		RFC Draft, Version 1.1, URL: http://www.ietf.org/
	internet-drafts/		internet-drafts/
	draft-vassilev-portable-symmetric-key-container-01.txt,		draft-vassilev-portable-symmetric-key-container-01.txt,
	August 2006.		August 2006.
	skipping to change at page 31, line 17 ¶		skipping to change at page 30, line 17 ¶
	The following syntax specification uses the widely adopted XML schema		The following syntax specification uses the widely adopted XML schema
	format as defined by a W3C recommendation		format as defined by a W3C recommendation
	(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax		(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
	definition in the XML Schema Definition format (XSD)		definition in the XML Schema Definition format (XSD)
	All implementations of this standard must comply with the schema		All implementations of this standard must comply with the schema
	below.		below.
	<?xml version="1.0" encoding="UTF-8" ?>		<?xml version="1.0" encoding="UTF-8" ?>
	<schema xmlns="http://www.w3.org/2001/XMLSchema"		<schema xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:oath-kp="http://www.openauthentication.org/OATH/2006/10/DSKPP"		xmlns:oath-dskpp="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/PSKC"		xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
	xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"		xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"		xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	targetNamespace="http://www.openauthentication.org/OATH/2006/10/DSKPP"		targetNamespace="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<import namespace="http://www.w3.org/2000/09/xmldsig#"		<import namespace="http://www.w3.org/2000/09/xmldsig#"
	schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/		schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
	xmldsig-core-schema.xsd"/>		xmldsig-core-schema.xsd"/>
	<import		<import
	namespace="http://www.openauthentication.org/OATH/2006/08/PSKC"		namespace="http://www.openauthentication.org/OATH/2006/10/PSKC"
	schemaLocation="http://www.openauthentication.org/OATH/2006/08/PSKC/		schemaLocation="http://www.openauthentication.org/OATH/2006/10/PSKC/
	oath_pskc_schema_v1.1.xsd"/>		oath_pskc_schema_v1.2.xsd"/>
	<import		<import
	namespace="http://www.openauthentication.org/OATH/2006/08/Logo"		namespace="http://www.openauthentication.org/OATH/2006/08/Logo"
	schemaLocation="http://www.openauthentication.org/OATH/2006/08/Logo/		schemaLocation="http://www.openauthentication.org/OATH/2006/08/Logo/
	oath_logotype_v1.0.xsd"/>		oath_logotype_v1.0.xsd"/>
	<annotation>		<annotation>
	<documentation xml:lang="en">XML Schema for OATH Dynamical		<documentation xml:lang="en">XML Schema for OATH Dynamical
	Symmetric Key Provisioning Web Services</documentation>		Symmetric Key Provisioning Web Services</documentation>
	</annotation>		</annotation>
	<complexType name="MessageAbstractType" abstract="true">		<complexType name="MessageAbstractType" abstract="true">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Abstract class for all messages in this protocol.		Abstract class for all messages in this protocol.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<attribute name="version" type="oath-kp:VersionType"		<attribute name="version" type="oath-dskpp:VersionType"
	use="required"/>		use="required"/>
	</complexType>		</complexType>
	<simpleType name="VersionType" final="restriction">		<simpleType name="VersionType" final="restriction">
	<restriction base="string">		<restriction base="string">
	<pattern value="\d{1,9}\.\d{0,9}"/>		<pattern value="\d{1,9}\.\d{0,9}"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<complexType name="RequestAbstractType" abstract="true">		<complexType name="RequestAbstractType" abstract="true">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Abstract class for all request messages. Id is a pseudo-random		Abstract class for all request messages. Id is a pseudo-random
	number used for request-response matching.		number used for request-response matching.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<complexContent>		<complexContent>
	<extension base="oath-kp:MessageAbstractType">		<extension base="oath-dskpp:MessageAbstractType">
	<sequence>		<sequence>
	<element ref="ds:Signature" minOccurs="0"/>		<element ref="ds:Signature" minOccurs="0"/>
	</sequence>		</sequence>
	<attribute name="id" type="oath-kp:IdentifierType"		<attribute name="requestId" type="oath-dskpp:IdentifierType"/>
	use="optional"/>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<complexType name="ResponseAbstractType" abstract="true">		<complexType name="ResponseAbstractType" abstract="true">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Abstract class for all responses messages.		Abstract class for all responses messages.
	RequestId contains the Id received in the request.		RequestId contains the Id received in the request.
	Response messages also contains a status indicating success		Response messages also contains a status indicating success
	or cause of failure.		or cause of failure.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<complexContent>		<complexContent>
	<extension base="oath-kp:MessageAbstractType">		<extension base="oath-dskpp:MessageAbstractType">
	<sequence>		<sequence>
	<element name="Status" type="oath-kp:StatusType"/>		<element name="Status" type="oath-dskpp:StatusType"/>
	</sequence>		</sequence>
	<attribute name="requestId" type="oath-kp:IdentifierType"		<attribute name="requestId" type="oath-dskpp:IdentifierType"/>
	use="optional"/>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<complexType name="StatusType">		<complexType name="StatusType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Contains a status code indicating success or causes of failure,		Contains a status code indicating success or causes of failure,
	and a status message that includes a brief description.		and a status message that includes a brief description.
	</documentation>		</documentation>
	skipping to change at page 33, line 4 ¶		skipping to change at page 31, line 50 ¶
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<complexType name="StatusType">		<complexType name="StatusType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Contains a status code indicating success or causes of failure,		Contains a status code indicating success or causes of failure,
	and a status message that includes a brief description.		and a status message that includes a brief description.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<sequence>		<sequence>
	<element name="StatusCode" type="oath-kp:StatusCodeType"/>		<element name="StatusCode" type="oath-dskpp:StatusCodeType"/>
	<element name="StatusMessage" type="string" minOccurs="0"/>		<element name="StatusMessage" type="string" minOccurs="0"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	<simpleType name="StatusCodeType">		<simpleType name="StatusCodeType">
	<restriction base="string">		<restriction base="string">
	<enumeration value="Continue"/>		<enumeration value="Continue"/>
	<enumeration value="Success"/>		<enumeration value="Success"/>
	<enumeration value="Abort"/>		<enumeration value="Abort"/>
	<enumeration value="UnsupportedVersion"/>		<enumeration value="UnsupportedVersion"/>
	skipping to change at page 33, line 42 ¶		skipping to change at page 32, line 39 ¶
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Authentication data holder for a request. When authentication		Authentication data holder for a request. When authentication
	credential is of type "ACTIVATIONCODE", the data can be any		credential is of type "ACTIVATIONCODE", the data can be any
	one of the three activation code related types.		one of the three activation code related types.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<sequence>		<sequence>
	<element name="ClientId" type="anyURI" minOccurs="0"/>		<element name="ClientId" type="anyURI" minOccurs="0"/>
	<choice minOccurs="0">		<choice minOccurs="0">
	<element name="ActivationCode"		<element name="ActivationCode"
	type="oath-kp:ActivationCodeType"/>		type="oath-dskpp:ActivationCodeType"/>
	<element name="ActivationCodeDigest"		<element name="ActivationCodeDigest"
	type="oath-kp:ActivationCodeDigestType"/>		type="oath-dskpp:ActivationCodeDigestType"/>
	<element name="ActivationCodeMac"		<element name="ActivationCodeMac"
	type="oath-kp:ActivationCodeMacType"/>		type="oath-dskpp:ActivationCodeMacType"/>
	<any namespace="##other" processContents="strict"/>		<any namespace="##other" processContents="strict"/>
	</choice>		</choice>
	</sequence>		</sequence>
	<attribute name="form" type="oath-kp:AuthDataFormType"		<attribute name="form" type="oath-dskpp:AuthDataFormType"
	use="optional" default="ACTIVATIONCODE"/>		default="ACTIVATIONCODE"/>
	</complexType>		</complexType>
	<simpleType name="AuthDataFormType">		<simpleType name="AuthDataFormType">
	<restriction base="string">		<restriction base="string">
	<enumeration value="ACTIVATIONCODE"/>		<enumeration value="ACTIVATIONCODE"/>
	<enumeration value="CERTIFICATE"/>		<enumeration value="CERTIFICATE"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<simpleType name="CredentialFormatType">		<simpleType name="SecretContainerFormatType">
	<restriction base="string">		<restriction base="string">
	<enumeration value="PSKC"/>		<enumeration value="PSKC"/>
	<enumeration value="PKCS12"/>		<enumeration value="PKCS12"/>
	<enumeration value="XMLPKCS5"/>		<enumeration value="XMLPKCS5"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<simpleType name="NonceType">		<simpleType name="NonceType">
	<restriction base="base64Binary">		<restriction base="base64Binary">
	<minLength value="8"/>		<minLength value="8"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<element name="GetAuthNonce" type="oath-kp:GetAuthNonceType"/>		<element name="GetAuthNonce" type="oath-dskpp:GetAuthNonceType"/>
	<complexType name="GetAuthNonceType">		<complexType name="GetAuthNonceType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:RequestAbstractType">		<extension base="oath-dskpp:RequestAbstractType">
	<sequence>		<sequence>
	<element name="DeviceId" type="oath-pskc:DeviceIdType"/>		<element name="DeviceId" type="oath-pskc:DeviceIdType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<element name="GetAuthNonceResponse"		<element name="GetAuthNonceResponse"
	type="oath-kp:GetAuthNonceResponseType"/>		type="oath-dskpp:GetAuthNonceResponseType"/>
	<complexType name="GetAuthNonceResponseType">		<complexType name="GetAuthNonceResponseType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:ResponseAbstractType">		<extension base="oath-dskpp:ResponseAbstractType">
	<sequence minOccurs="0" maxOccurs="unbounded">		<sequence minOccurs="0" maxOccurs="unbounded">
	<element name="CredentialId"		<element name="SecretId"
	type="oath-kp:CredentialIdType"/>		type="string"/>
	<element name="ServiceId" type="oath-kp:IdentifierType"/>		<element name="ServiceId" type="oath-dskpp:IdentifierType"/>
	</sequence>		</sequence>
	<attribute name="serverNonce" type="oath-kp:NonceType"/>		<attribute name="serverNonce" type="oath-dskpp:NonceType"
	<attribute name="sessionId" type="oath-kp:IdentifierType"		use="required"/>
	use="optional"/>		<attribute name="sessionId" type="oath-dskpp:IdentifierType"/>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<simpleType name="IdentifierType">		<simpleType name="IdentifierType">
	<restriction base="string">		<restriction base="string">
	<maxLength value="128"/>		<maxLength value="128"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<element name="GetSharedSecret" type="oath-kp:GetSharedSecretType"/>		<element name="GetSharedSecret"
			type="oath-dskpp:GetSharedSecretType"/>
	<complexType name="GetSharedSecretType">		<complexType name="GetSharedSecretType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:RequestAbstractType">		<extension base="oath-dskpp:RequestAbstractType">
	<sequence maxOccurs="unbounded">		<sequence maxOccurs="unbounded">
	<element name="CredentialId"		<element name="SecretId"
	type="oath-kp:CredentialIdType" minOccurs="0"/>		type="string" minOccurs="0"/>
	<element name="ClientType" type="oath-kp:ClientTypeType"		<element name="ClientForm" type="oath-dskpp:ClientFormType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="DeviceId" type="oath-pskc:DeviceIdType"		<element name="DeviceId" type="oath-pskc:DeviceIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="AuthenticationData"		<element name="AuthenticationData"
	type="oath-kp:AuthenticationDataType" minOccurs="0"/>		type="oath-dskpp:AuthenticationDataType" minOccurs="0"/>
	<element name="SecretAlgorithm"		<element name="SecretAlgorithm"
	type="oath-pskc:SecretAlgorithmType"		type="oath-pskc:SecretAlgorithmType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="OtpAlgorithm"		<element name="Usage"
	type="oath-pskc:OtpAlgorithmIdentifierType"		type="oath-pskc:UsageType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="SharedSecretDeliveryMethod"		<element name="SharedSecretDeliveryMethod"
	type="oath-kp:SharedSecretDeliveryMethodType"		type="oath-dskpp:SharedSecretDeliveryMethodType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="SupportedEncryptionAlgorithm"		<element name="SupportedEncryptionAlgorithm"
	type="oath-pskc:EncryptionAlgorithmType"		type="oath-pskc:EncryptionAlgorithmType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="LogoPreference"		<element name="LogoPreference"
	type="oath-logo:LogoImageInfoType" minOccurs="0"/>		type="oath-logo:LogoImageInfoType" minOccurs="0"/>
	<element name="Extension" type="oath-kp:ExtensionType"		<element name="Extension" type="oath-dskpp:ExtensionType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<complexType name="ExtensionType" abstract="true">		<complexType name="ExtensionType" abstract="true">
	<sequence>
	<element name="ExtensionId" type="anyURI"/>
	<element name="ExtensionValue" type="base64Binary"/>
	</sequence>
	<attribute name="critical" type="boolean"/>		<attribute name="critical" type="boolean"/>
	</complexType>		</complexType>
			<complexType name="PropertyExtensionType">
			<complexContent>
			<extension base="oath-dskpp:ExtensionType">
			<sequence>
			<element name="Name" type="string"/>
			<element name="Value" type="string" minOccurs="0"/>
			</sequence>
			</extension>
			</complexContent>
			</complexType>
	<simpleType name="CredentialIdType">		<simpleType name="ClientFormType">
	<annotation>
	<documentation xml:lang="en">
	Credential identifier. Limited to 40 characters.
	</documentation>
	</annotation>
	<restriction base="string">
	<maxLength value="40"/>
	</restriction>
	</simpleType>
	<simpleType name="ClientTypeType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	List of supported device types.		List of supported device types.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<restriction base="string">		<restriction base="string">
	<enumeration value="DEVICE"/>		<enumeration value="DEVICE"/>
	<enumeration value="MOBILEPHONE"/>		<enumeration value="MOBILEPHONE"/>
	<enumeration value="DESKTOP"/>		<enumeration value="DESKTOP"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<simpleType name="HMACAlgorithmType">
	<annotation>
	<documentation xml:lang="en">
	List of supported HMAC algorithms.
	</documentation>
	</annotation>
	<restriction base="string">
	<enumeration value="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
	<enumeration
	value="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
	<enumeration
	value="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512"/>
	</restriction>
	</simpleType>
	<simpleType name="DigestAlgorithmType">
	<annotation>
	<documentation xml:lang="en">
	List of supported message digest algorithms.
	</documentation>
	</annotation>
	<restriction base="string">
	<enumeration value="http://www.w3.org/2000/09/xmldsig#sha1"/>
	<enumeration
	value="http://www.w3.org/2001/04/xmldsig-more#sha256"/>
	<enumeration
	value="http://www.w3.org/2001/04/xmldsig-more#sha512"/>
	</restriction>
	</simpleType>
	<simpleType name="ActivationCodeType">		<simpleType name="ActivationCodeType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Maximum length of activation code restricted to 20 bytes		Maximum length of activation code restricted to 20 bytes
	</documentation>		</documentation>
	</annotation>		</annotation>
	<restriction base="string">		<restriction base="string">
	<maxLength value="20"/>		<maxLength value="20"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<complexType name="ActivationCodeDigestType">		<complexType name="ActivationCodeDigestType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Includes a digest of activation code.		Includes a digest of activation code.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<simpleContent>		<simpleContent>
	<extension base="base64Binary">		<extension base="base64Binary">
	<attribute name="algorithm" type="oath-kp:DigestAlgorithmType"		<attribute name="algorithm" type="oath-dskpp:HashAlgorithmType"
	use="required"/>		use="required"/>
	</extension>		</extension>
	</simpleContent>		</simpleContent>
	</complexType>		</complexType>
	<complexType name="ActivationCodeMacType">		<complexType name="ActivationCodeMacType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	Includes a HMAC of activation code with nonce as key.		Includes a HMAC of activation code with nonce as key.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<sequence>		<sequence>
	<element name="Data" type="base64Binary"/>		<element name="Data" type="base64Binary"/>
	<element name="Nonce" type="oath-kp:NonceType" minOccurs="0"/>		<element name="Nonce" type="oath-dskpp:NonceType" minOccurs="0"/>
	</sequence>		</sequence>
	<attribute name="algorithm" type="oath-kp:CredentialIdType"		<attribute name="algorithm" type="oath-pskc:DigestAlgorithmType"
	use="required"/>		use="required"/>
	<attribute name="nonceId" type="oath-kp:IdentifierType"		<attribute name="nonceId" type="oath-dskpp:IdentifierType"/>
	use="optional"/>
	</complexType>		</complexType>
	<simpleType name="SharedSecretDeliveryMethodType">		<simpleType name="SharedSecretDeliveryMethodType">
	<annotation>		<annotation>
	<documentation xml:lang="en">		<documentation xml:lang="en">
	List of supported transport protocols.		List of supported transport protocols.
	</documentation>		</documentation>
	</annotation>		</annotation>
	<restriction base="string">		<restriction base="string">
	<enumeration value="HTTP"/>		<enumeration value="HTTP"/>
	skipping to change at page 38, line 26 ¶		skipping to change at page 36, line 38 ¶
	<enumeration value="SMS"/>		<enumeration value="SMS"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<complexType name="CredentialType">		<complexType name="CredentialType">
	<choice>		<choice>
	<element name="SecretContainer"		<element name="SecretContainer"
	type="oath-pskc:SecretContainerType"/>		type="oath-pskc:SecretContainerType"/>
	<any namespace="##other" processContents="strict"/>		<any namespace="##other" processContents="strict"/>
	</choice>		</choice>
	<attribute name="format" type="oath-kp:CredentialFormatType"		<attribute name="format"
			type="oath-dskpp:SecretContainerFormatType"
	default="PSKC"/>		default="PSKC"/>
	</complexType>		</complexType>
	<element name="GetSharedSecretResponse"		<element name="GetSharedSecretResponse"
	type="oath-kp:GetSharedSecretResponseType"/>		type="oath-dskpp:GetSharedSecretResponseType"/>
	<complexType name="GetSharedSecretResponseType">		<complexType name="GetSharedSecretResponseType">
	<complexContent>		<complexContent>
	<extension base="oath-kp:ResponseAbstractType">		<extension base="oath-dskpp:ResponseAbstractType">
	<sequence minOccurs="0">		<sequence minOccurs="0">
	<element name="SharedSecretDeliveryMethod"		<element name="SharedSecretDeliveryMethod"
	type="oath-kp:SharedSecretDeliveryMethodType"		type="oath-dskpp:SharedSecretDeliveryMethodType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="Credential" type="oath-kp:CredentialType"		<choice>
	minOccurs="0"/>		<element name="SecretContainer"
	<element name="Extension" type="oath-kp:ExtensionType"		type="oath-pskc:SecretContainerType"/>
	minOccurs="0" maxOccurs="unbounded"/>		<any namespace="##other" processContents="strict"/>
			</choice>
			<element name="Extension" type="oath-dskpp:ExtensionType"
			minOccurs="0" maxOccurs="unbounded"/>
	</sequence>		</sequence>
			<attribute name="format"
			type="oath-dskpp:SecretContainerFormatType" default="PSKC"/>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	</schema>		</schema>
	Appendix B. Example Requests and Responses		Appendix B. Example Requests and Responses
	All examples are syntactically correct and compatible with the XML		All examples are syntactically correct and compatible with the XML
	schema in Appendix B. However, <Signature>, Secret <Value> and		schema in Appendix B. However, <Signature>, Secret <Value> and
	Secret <ValueDigest> data values are fictitious.		Secret <ValueDigest> data values are fictitious.
	B.1. Simple client message exchange for acquiring a credential with an		B.1. Simple client message exchange for acquiring a credential with an
	activation code		activation code
	A client can directly acquire a credential with request message type		A client can directly acquire a credential with request message type
	GetSharedSecret with an activation code for authentication over a SSL		GetSharedSecret with an activation code for authentication over a SSL
	enabled provisioning service.		enabled provisioning service.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<GetSharedSecret xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		<GetSharedSecret xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/DSKPP		xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
	oath_dskpp_schema_v1.0.xsd"		xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
	xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/PSKC"		xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"		requestId="1234abcd" version="1.0">
	xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"		<ClientForm>MOBILEPHONE</ClientForm>
	id="1234abcd"		<DeviceId>
	version="1.0">		<oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>
	<ClientType>MOBILEPHONE</ClientType>		<oath-pskc:SerialNo>XL0000000001234</oath-pskc:SerialNo>
	<DeviceId>		<oath-pskc:Model>U2</oath-pskc:Model>
	<oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>		</DeviceId>
	<oath-pskc:SerialNo>XL0000000001234</oath-pskc:SerialNo>		<AuthenticationData form="ACTIVATIONCODE">
	<oath-pskc:Model>U2</oath-pskc:Model>		<ActivationCode>12345678</ActivationCode>
	</DeviceId>		</AuthenticationData>
	<AuthenticationData form="ACTIVATIONCODE">		<SecretAlgorithm>HOTP</SecretAlgorithm>
	<ActivationCode>12345678</ActivationCode>		<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
	</AuthenticationData>		<SupportedEncryptionAlgorithm>PBE-3DES168-CBC
	<SecretAlgorithm>HOTP</SecretAlgorithm>		</SupportedEncryptionAlgorithm>
	<OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS" mode="PLAIN-SINGLE"/>		</GetSharedSecret>
	<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
	<SupportedEncryptionAlgorithm>PBE-3DES168-CBC
	</SupportedEncryptionAlgorithm>
	</GetSharedSecret>
	Server responses with an encrypted credential in		Server responses with an encrypted credential in
	GetSharedSecretResponse upon approval.		GetSharedSecretResponse upon approval.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<GetSharedSecretResponse		<GetSharedSecretResponse
	xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	xsi:schemaLocation="http://www.openauthentication.org/OATH/2006/10/DSKPP		requestId="1234abcd" version="1.0" format="PSKC">
	oath_dskpp_schema_v1.0.xsd"		<Status>
	requestId="1234abcd" version="1.0">		<StatusCode>Success</StatusCode>
	<Status>		<StatusMessage>Success</StatusMessage>
	<StatusCode>Success</StatusCode>		</Status>
	<StatusMessage>Success</StatusMessage>		<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
	</Status>		<SecretContainer version="1.0"
	<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>		xmlns="http://www.openauthentication.org/OATH/2006/10/PSKC">
	<Credential format="PSKC">		<EncryptionMethod algorithm="PBE-3DES168-CBC">
	<SecretContainer version="1.0"		<PBESalt>y6TzckeLRQw=</PBESalt>
	xmlns="http://www.openauthentication.org/OATH/2006/08/PSKC">		<PBEIterationCount>999</PBEIterationCount>
	<EncryptionMethod algorithm="PBE-3DES168-CBC">		</EncryptionMethod>
	<PBESalt>y6TzckeLRQw=</PBESalt>		<DigestMethod algorithm="HMAC-SHA1"/>
	<PBEIterationCount>999</PBEIterationCount>		<Device>
	</EncryptionMethod>		<Secret SecretAlgorithm="HOTP" SecretId="SDU312345678">
	<DigestMethod algorithm="HMAC-SHA1"/>		<Issuer>CredentialIssuer</Issuer>
	<Device>		<Usage otp="true">
	<Secret SecretAlgorithm="HOTP" SecretId="SDU312345678">		<ResponseFormat format="DECIMAL" length="6"/>
	<Issuer>CredentialIssuer</Issuer>		</Usage>
	<Usage otp="true">		<FriendlyName>MyFirstToken</FriendlyName>
	<Counter>0</Counter>		<Data Name="SECRET">
	<Response format="DECIMAL" length="6"/>		<Value>
	</Usage>		7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==
	<FriendlyName>MyFirstToken</FriendlyName>		</Value>
	<Data>		<ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=</ValueDigest>
	<Value>		</Data>
	7JHUyp3azOkqJENSsh6b2vxXzwGBYypzJxEr+ikQAa229KV/BgZhGA==		<Data Name="COUNTER">
	</Value>		<Value>9TD4yaItFZg=</Value>
	<ValueDigest>WldjTHZwRm9YTkhBRytseDMrUnc=		<ValueDigest>HuYEuuk9K/oZPgfZS7kD+dwmiDg=</ValueDigest>
	</ValueDigest>		</Data>
	</Data>		<Expiry>10/30/2009</Expiry>
	<AccessRules/>		</Secret>
	<Expiry>2007-04-30T12:00:00</Expiry>		</Device>
	</Secret>		</SecretContainer>
	</Device>		</GetSharedSecretResponse>
	</SecretContainer>
	</Credential>
	</GetSharedSecretResponse>
	B.2. Full message exchanges for a client over a non-secure channel		B.2. Full message exchanges for a client over a non-secure channel
	A client first sends a request to acquire server nonce.		A client first sends a request to acquire server nonce.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<GetAuthNonce		<GetAuthNonce
	xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"		xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	id="1234abcd"		requestId="1234abcd"
	version="1.0">		version="1.0">
	<ClientId>FA0033F4550B01FFDA05</ClientId>		<ClientId>FA0033F4550B01FFDA05</ClientId>
	</GetAuthNonce>		</GetAuthNonce>
	Server replies with a nonce for the session with the following		Server replies with a nonce for the session with the following
	message.		message.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<GetAuthNonceResponse		<GetAuthNonceResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"		xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	version="1.0"		version="1.0"
	requestId="1234abcd"		requestId="1234abcd"
	serverNonce="cmFuZG9tc2VlZA0K"		serverNonce="cmFuZG9tc2VlZA0K"
	sessionId="SS00000001">		sessionId="SS00000001">
	<Status>		<Status>
	<StatusCode>Continue</StatusCode>		<StatusCode>Continue</StatusCode>
	</Status>		</Status>
	</GetAuthNonceResponse>		</GetAuthNonceResponse>
	The client requests a credential with authentication data constructed		The client requests a credential with authentication data constructed
	from an activation code and the nonce.		from an activation code and the nonce.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<GetSharedSecret		<GetSharedSecret xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/10/PSKC"
	xmlns:oath-pskc="http://www.openauthentication.org/OATH/2006/08/PSKC"		xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"
	xmlns:oath-logo="http://www.openauthentication.org/OATH/2006/08/Logo"		xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"
	xmlns="http://www.openauthentication.org/OATH/2006/10/DSKPP"		requestId="1234abcd" version="1.0">
	id="1234abcd"		<ClientForm>MOBILEPHONE</ClientForm>
	version="1.0">		<DeviceId>
	<ClientType>MOBILEPHONE</ClientType>		<oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>
	<DeviceId>		<oath-pskc:SerialNo>FA0033F4550B01FFDA05</oath-pskc:SerialNo>
	<oath-pskc:Manufacturer>ManufacturerABC</oath-pskc:Manufacturer>		<oath-pskc:Model>SPH-A900</oath-pskc:Model>
	<oath-pskc:SerialNo>FA0033F4550B01FFDA05</oath-pskc:SerialNo>		</DeviceId>
	<oath-pskc:Model>SPH-A900</oath-pskc:Model>		<AuthenticationData form="ACTIVATIONCODE">
	</DeviceId>		<ClientId>SS00000001</ClientId>
	<AuthenticationData form="ACTIVATIONCODE">		<ActivationCodeMac algorithm="HMAC-SHA1">
	<ClientId>SS00000001</ClientId>		<Data>WldjTHZwRm9YTkhBRytseDMrUnc=</Data>
	<ActivationCodeMac algorithm="HMAC-SHA1">		</ActivationCodeMac>
	<Data>WldjTHZwRm9YTkhBRytseDMrUnc=</Data>		</AuthenticationData>
	</ActivationCodeMac>		<SecretAlgorithm>HOTP</SecretAlgorithm>
	</AuthenticationData>		<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
	<SecretAlgorithm>HOTP</SecretAlgorithm>		<SupportedEncryptionAlgorithm>PBE-3DES168-CBC
	<OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS" mode="PLAIN-SINGLE"/>		</SupportedEncryptionAlgorithm>
	<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>		</GetSharedSecret>
	<SupportedEncryptionAlgorithm>PBE-3DES168-CBC
	</SupportedEncryptionAlgorithm>
	</GetSharedSecret>
	The server response message for this request is similar to the		The server response message for this request is similar to the
	example in the last section.		example in the last section.
	Appendix C. Transport Consideration		Appendix C. Transport Consideration
	The transport layer security may affect how a client can choose its		The transport layer security may affect how a client can choose its
	authentication choice and whether it can leverage some from the		authentication choice and whether it can leverage some from the
	transport layer. We consider the following three typical cases.		transport layer. We consider the following three typical cases.
End of changes. 121 change blocks.
	484 lines changed or deleted		429 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/