1. OTP-ValidationService John Linn, RSA Laboratories 11 May 2005

2. OTP-ValidationService (OTP-VS) Overview OTP-VS uses XML Schema, defines a web service request/response protocol to validate OTP credentials Using OTP-VS, a relying party (RP) can ask an authentication service (AS) whether OTP data that it has received successfully authenticates a claimant —OTP-VS uses OTP-WSS-Token to represent OTP data —Supports ancillary OTP-related functions (obtaining challenges, PIN management, resynchronization) —Validation transactions can be secured "in band" within OTP-VS protocol (using XML Signature, XML Encryption), externally (e.g., SSL/TLS, IPsec, WSS:SMS), or by relying on security properties of environment Generic service can be profiled to support the needs of particular OTP methods

3. OTP-VS Usage Scenario ClaimantRPAS Application Request with OTP OTP-VS User OTP-VS operates in a web service environment; claimant-RP protocol can be arbitrary

4. OTP-VS Premises and Assumptions RP has prior knowledge of the set of OTP methods that the AS supports Depending on method and situation, an OTP-VS transaction may span one or more request-response round trips —For example, could request and obtain challenge, then provide an OTPToken based on the challenge to be validated —For another example, PIN change, then authenticate using the new PIN SOAP binding defined, other bindings possible

5. OTP-VS Transaction Identifiers and Sequencing RequestID and SessionID identify the transaction to which messages belong —Client generates new RequestID for initial request —If more than single round-trip, server provides SessionID and client uses that value in subsequent RequestIDs SequenceID protects sequence integrity of multi-round transactions —Initialized by server, incremented for subsequent roundtrips

6. OTP-VS Status Framework Outer level: String codes with enumerated values (e.g., "Continue", "Complete", "Abort", "AccessDenied", others) —Any value except "Continue" or "Complete" terminates transaction Inner level: CredentialStatus —Generic StatusCodes: "OK", "Unknown", "Failed" — code, defined for method and/or environment — string, typically describing value

7. OTP-VS Signatures The element is of type ds:SignatureType from XML Signature and must be present when optional “native” OTP-ValidationService RP authentication is being used. The URI attribute of the element of the child element of the shall reference the complete element instance by being the NULL ("") reference (i.e., when present, the signature shall be made over a complete element, excluding the element itself; this is the http://www.w3.org/2000/09/xmldsig#enveloped-signature transform defined in XML Signature).http://www.w3.org/2000/09/xmldsig#enveloped-signature Before performing the signature calculation, the RP must canonicalize all elements the signature shall be made over, in accordance with Exclusive XML Canonicalization. The child element of the element SHALL identify the signing key. The AS must verify that the signing key is associated with the identified RP and must verify the signature before performing any security-related processing of the request.

8. OTP-VS Encryption A validation request or response may optionally be encrypted. In this case, a sender shall form an ordinary (i.e. plaintext) validation request or response, encrypt its content using the XML Encryption “Content” type, and then replace the contents of the plaintext validation request or response with an or element that carries the encrypted data in its element. In a reciprocal fashion, a recipient of a validation request or response carrying an or element shall decrypt the child of this element and replace the content of the received validation request or response (i.e. the or element itself) with the decrypted data, before processing the content of the request. When applying both encryption and signature, signatures are applied first (on plaintext data) Note: Encryption approach does not protect top-level message attributes

9. OTP-VS Selected Basic Types

10. OTP-VS Status Codes

11. OTP-VS Payload and DataRequest

12. OTP-VS NewPIN

13. OTP-VS ValidationRequest Message sent to Validation service to initiate or continue validation of OTP credentials.

14. OTP-VS ValidationResponse Message sent from Validation service responding to a validation request. <element name="credentialStatus" type="otps-vs:CredentialStatus" minOccurs=”0”/>

15. OTP-VS SOAP Binding Aspects OTP-VS requests and responses carried within SOAP bodies —Single unencoded request or response carried in a body SOAP faults generated only for messages that cannot be processed at OTP-ValidationService layer —Other errors reported within OTP-VS status framework SOAPAction value defined for optional HTTP header use, other HTTP headers unconstrained —Cache-Control should be set to disable caching

16. OTP-VS Security Service Requirements Authentication —Generally AS to RP, sometimes RP to AS as well Confidentiality —Generally when carrying OTP or PIN values, other needs vary Integrity —Generally, at per-message and transaction sequence levels Non-repudiation —May be needed for some accountability scenarios

17. OTP-VS Possible Futures Schema changes —Adopt UpperCamelCase naming convention —Alignment with OTP-WSS-Token identifiers —XML Schema namespace qualification? Other methods or extended facilities —Profile to carry EAP within OTP-VS web service transaction?

18. OTP-VS Next Steps Agreement and stabilization of document content Consideration of added features or new methods —Methods can be specified separately from base document Possible future contribution of document?