90 likes | 262 Views
OTP-ValidationService: Summary, Status, and Next Steps. OTPS Workshop, February 2006. OTP-ValidationService (OTP-VS) Overview. OTP-VS uses XML Schema, defines a web service request/response protocol to validate OTP credentials
E N D
OTP-ValidationService: Summary, Status, and Next Steps OTPS Workshop, February 2006
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
OTP-VS Usage Scenario Application Request with OTP OTP-VS Claimant RP AS User OTP-VS operates in a web service environment; claimant-RP protocol can be arbitrary
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 • RequestID and SessionID identify a message's transaction, SequenceID supports sequence integrity • Two-level status framework: transaction status, credential status • SOAP binding defined, other bindings possible
Draft 4 Status • Current Draft 4 released January 2006, relatively few changes from Draft 3 • Added AuxiliaryValidationData, replacing ExtendedStatusCode with more general approach • Extended CertHash to bind VS as well as RP • Removed remaining PIN management references • Allowed advisory, non-failure LostToken status • Various clarifications and editorial changes • Unless significant issues identified, expect to declare this as final OTP-VS 1.0 draft following workshop
Draft 3 status (1 of 2) • Draft 3 (November 2005) responded to issues discussed on list and at October workshop • Expanded string comparison rules • Additional error codes (SignatureValidationFailed, SignatureRequired, DecryptionFailed) • Removed PIN management from scope • Separated request from response payloads • Allowed challenge requests to identify user and/or OTP component
Draft 3 status (2 of 2) • Additional changes in Draft 3: • Added CertHash to bind requester with certificate • Described that <Reason> values are generally defined at method level, included usage example • Also defined specific method-independent <Reason>s: LostToken, ExpiredToken, PINUpdate • Clarified <Message> end-user display (and associated internationalization) as out of scope, given functional focus on adminstrator interaction • Various other clarifications, simplifications, editorial changes
Areas Intended for Support, Independent Validation Sought • Challenge-response profile • Indicating authentication strength within verification responses • Example included in current draft • Supporting multiple challenge-response sets
OTP-VS Next Steps • Confirmation of document content as V1.0 • Consideration of profiles for additional OTP methods • Profiles can be specified separately from base document • Possible contribution of document to external forum?