otp validationservice summary status and next steps n.
Skip this Video
Loading SlideShow in 5 Seconds..
OTP-ValidationService: Summary, Status, and Next Steps PowerPoint Presentation
Download Presentation
OTP-ValidationService: Summary, Status, and Next Steps

Loading in 2 Seconds...

play fullscreen
1 / 9

OTP-ValidationService: Summary, Status, and Next Steps - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

OTP-ValidationService: Summary, Status, and Next Steps

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
otp validationservice otp vs overview
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
OTP-VS Usage Scenario

Application Request with OTP






OTP-VS operates in a web service environment; claimant-RP protocol can be arbitrary

otp vs premises and assumptions
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
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 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
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
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
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?