


Network Working Group                                           P. Hoyer
Internet-Draft                                             ActivIdentity
Intended status: Standards Track                                T. Moses
Expires: July 31, 2010                                           Entrust
                                                                  M. Pei
                                                                VeriSign
                                                              S. Machani
                                                              Diversinet
                                                        January 27, 2010


                                 VALID
                          draft-hoyer-valid-01

Abstract

   This document describes a Web-service interface standard for an
   authentication-data validation service that supports risk-based,
   multi-factor authentication.This standard enables enterprises to
   deploy best-of-breed solutions combining components from different
   vendors into the same infrastructure.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 31, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Hoyer, et al.             Expires July 31, 2010                 [Page 1]

Internet-Draft                    VALID                     January 2010


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Namespaces . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Authentication-Data Validation Service Interface overview  . .  7
     2.1.  Authentication data communication  . . . . . . . . . . . .  7
     2.2.  Verified attributes  . . . . . . . . . . . . . . . . . . .  7
     2.3.  Challenge/response . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Token collections  . . . . . . . . . . . . . . . . . . . .  8
   3.  Communication patterns . . . . . . . . . . . . . . . . . . . .  9
     3.1.  In-band authentication . . . . . . . . . . . . . . . . . .  9
       3.1.1.  In-band Challenge/Response . . . . . . . . . . . . . .  9
       3.1.2.  In-band 2 way Challenge/Response . . . . . . . . . . . 10
     3.2.  Out-of-band challenge  . . . . . . . . . . . . . . . . . . 11
     3.3.  Out-of-band response . . . . . . . . . . . . . . . . . . . 12
     3.4.  Client supplies challenge  . . . . . . . . . . . . . . . . 13
     3.5.  End-user obtains assertions Out-of-band from server  . . . 13
   4.  Asynchronous communication . . . . . . . . . . . . . . . . . . 15
     4.1.  Out-of-band challenge  . . . . . . . . . . . . . . . . . . 15
     4.2.  Out-of-band response . . . . . . . . . . . . . . . . . . . 15
   5.  User centric and device centric (pseudonymous)
       authentication models  . . . . . . . . . . . . . . . . . . . . 16
     5.1.  User Centric authentication model  . . . . . . . . . . . . 16
     5.2.  Device Centric authentication model  . . . . . . . . . . . 16
   6.  Authentication moving factor resync  . . . . . . . . . . . . . 17
     6.1.  Automatic re-sync based on authentication data . . . . . . 17
     6.2.  Manual re-sync based on presenting moving factor values  . 17
   7.  Policy models  . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  Common message contents  . . . . . . . . . . . . . . . . . . . 20
     8.1.  Request Security Token . . . . . . . . . . . . . . . . . . 20
     8.2.  Request Security Token Response  . . . . . . . . . . . . . 21
   9.  Mechanism-specific message contents  . . . . . . . . . . . . . 23



Hoyer, et al.             Expires July 31, 2010                 [Page 2]

Internet-Draft                    VALID                     January 2010


   10. Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 24
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
     11.1. XML namespace registration . . . . . . . . . . . . . . . . 25
     11.2. VALID Version Registry . . . . . . . . . . . . . . . . . . 25
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     14.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Appendix A.  WSDL  . . . . . . . . . . . . . . . . . . . . . . . . 30
   Appendix B.  Mechanism specific message contents . . . . . . . . . 32
     B.1.  Username/password  . . . . . . . . . . . . . . . . . . . . 32
     B.2.  In band one-time-password (OTP)  . . . . . . . . . . . . . 33
     B.3.  In band one-time-password (OTP) token synchronization  . . 35
     B.4.  In band challenge/response . . . . . . . . . . . . . . . . 37
     B.5.  Out-of-band challenge  . . . . . . . . . . . . . . . . . . 39
     B.6.  Out-of-band response . . . . . . . . . . . . . . . . . . . 40
     B.7.  Client supplies challenge  . . . . . . . . . . . . . . . . 42
     B.8.  Challenge/response with signature  . . . . . . . . . . . . 43
   Appendix C.  Use Cases . . . . . . . . . . . . . . . . . . . . . . 45
     C.1.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 45
       C.1.1.  OTP Validation . . . . . . . . . . . . . . . . . . . . 45
       C.1.2.  Challenge/Response Validation - Server generated
               challenge  . . . . . . . . . . . . . . . . . . . . . . 45
       C.1.3.  Challenge/Response Validation - User generated
               challenge  . . . . . . . . . . . . . . . . . . . . . . 46
       C.1.4.  2-way mutual Challenge/Response Validation . . . . . . 46
       C.1.5.  OTP Validation + Server managed PIN  . . . . . . . . . 46
       C.1.6.  MatrixCardValidation - Server generated challenge  . . 46
     C.2.  Synchronisation Use Cases  . . . . . . . . . . . . . . . . 46
       C.2.1.  OTP Token Resync with the Next OTPs  . . . . . . . . . 47
       C.2.2.  OTP Token Resync with Moving Factor  . . . . . . . . . 47
   Appendix D.  Requirements  . . . . . . . . . . . . . . . . . . . . 48
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49

















Hoyer, et al.             Expires July 31, 2010                 [Page 3]

Internet-Draft                    VALID                     January 2010


1.  Introduction

   The Authentication-Data Validation Service Interface definition
   (VALID) describes a Web-service interface for a validation server.
   The specification reuses data definitions from [SAML], [WS-Security]
   and [WS-Trust] and operates over version 1.2 of [SOAP].  Upon
   successful validation, the validation server returns a SAML assertion
   containing verified attributes of the authenticated end-user or a
   hardware or software device under the end-user's control.
   Communications between the end-user and the application are not
   required to follow the Web-services programming model.

1.1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Notation

   This specification uses the following syntax to define outlines for
   messages:

      The syntax appears as an XML instance.

      Characters are appended to elements and attributes to indicate
      cardinality:

      "?" (0 or 1)

      "*" (0 or more)

      "+" (1 or more)

      The character "|" is used to indicate a choice between
      alternatives.

      The characters "(" and ")" are used to indicate that contained
      items are to be treated as a group with respect to cardinality or
      choice.

      The characters "[" and "]" are used to call out references and
      property names.

      Additional child elements and/or attributes MAY be added at the
      indicated extension points (see Section 10) but MUST NOT
      contradict the semantics of the parent and/or owner, respectively.
      By default, if a receiver does not recognize an extension, the



Hoyer, et al.             Expires July 31, 2010                 [Page 4]

Internet-Draft                    VALID                     January 2010


      receiver SHOULD ignore the extension; exceptions to this
      processing rule, if any, are clearly indicated below.

      XML namespace prefixes (see Table 1) are used to indicate the
      namespace of the element being defined.

      Elements and Attributes defined by this specification are referred
      to in the text of this document using XPath 1.0 expressions.
      Extensibility points are referred to using an extended version of
      this syntax:



         An element extensibility point is referred to using {any} in
         place of the element name.  This indicates that any element
         name can be used, from any namespace other than the namespace
         of this specification.

         An attribute extensibility point is referred to using @{any} in
         place of the attribute name.  This indicates that any attribute
         name can be used, from any namespace other than the namespace
         of this specification

1.3.  Namespaces

   The following XML namespace prefixes are used in the specification.

   env:    http://www.w3.org/2003/05/soap-envelope
   pskc: urn:ietf:params:xml:ns:keyprov:pskc
   saml:   urn:oasis:names:tc:SAML:2.0:assertion
   valid:  urn:ietf:params:xml:ns:valid
   wsp:    http://www.w3.org/ns/ws-policy
   wss:    http://docs.oasis-open.org/wss/2004/01/
            oasis-200401-wss-wssecurity-secext-1.0
   wst:    http://docs.oasis-open.org/ws-sx/ws-trust/200512
   wst14:  http://docs.oasis-open.org/ws-sx/ws-trust/200802
   xsd:    http://www.w3.org/2001/XMLSchema

1.4.  Terminology

   The following terms are used in this document.

   Application:  The system component that controls access to sensitive
      resources by authenticated end-users.







Hoyer, et al.             Expires July 31, 2010                 [Page 5]

Internet-Draft                    VALID                     January 2010


   Authentication data:  Information exchanged between the end-user and
      the validation server as part of the authentication process.  For
      example a password, an OTP, the response to a challenge, etc.

   Authentication policy:  The combination of authentication mechanisms
      required to complete successfully before access may be granted.

   Client :  See "Application".

   End-user:  The authentication subject.

   Moving factor:  The factor that makes a one time password
      computationally unique in combination with a fixed key.  For
      example the increasing event counter value in [HOTP].

   Server:  See "Validation server".

   Validation server:  The system component that validates
      authentication data.
































Hoyer, et al.             Expires July 31, 2010                 [Page 6]

Internet-Draft                    VALID                     January 2010


2.  Authentication-Data Validation Service Interface overview

   The Authentication-Data Validation Service Interface allows
   communication of the following data elements in several different
   communication patterns as described in Section 3.  The interface is
   based mainly on [WS-Trust].  The following sections apply
   terminologies and concepts defined in [WS-Trust].

2.1.  Authentication data communication

   The specific requirements for authentication data communication
   depend upon the specific authentication mechanism.

   In-band authentication data SHALL be passed in the body of <wst:
   RequestSecurityToken> and <wst:RequestSecurityTokenResponse>
   elements.

2.2.  Verified attributes

   Upon successful validation of the authentication data, the validation
   server SHALL issue a SAML assertion containing verified end-user or
   token attributes, depending if the server is validating user
   identities (user centric authentication) or device/token
   (pseudonomous - token centric authentication) .  The client MAY
   provide a <wsp:Policy> element indicating which attributes it
   requires.  Required attributes SHALL be referenced using the <saml:
   Attribute> element, with the <saml:AttributeValue> child element
   omitted.

   The validation server MAY include the sub-set of the requested
   attributes whose verified values are known to it.  Otherwise, the
   validation server SHALL include all verified attributes whose values
   are known to it.  These attributes MUST be included in the SAML
   assertion.  They MUST also be included in a separate <wst:Claims>
   element.  In this way, the application may treat the assertion as
   opaque data, extracting any attributes it requires from the <wst:
   Claims> element.

   Attributes SHALL be expressed as <saml:Attribute> elements in
   accordance with the SAML V2.0 X.500/LDAP Attribute Profile.

2.3.  Challenge/response

   Multi-step authentication mechanisms are supported as shown here.







Hoyer, et al.             Expires July 31, 2010                 [Page 7]

Internet-Draft                    VALID                     January 2010


  Message     Direction            Cardinality

  Request     Client  -> Server    Exactly one
  Response    Client <-> Server    (Zero or more request-response pairs)
  Response    Client <-  Server    Exactly one

   The protocol terminates when the validation server either includes at
   least one security token according to [WS-Trust] in the response or
   returns an <env:Body/env:Fault> element.

2.4.  Token collections

   A set of tokens MAY be requested and issued in a single set of
   exchanges with the validation server using the "token collection"
   features of WS-Trust.




































Hoyer, et al.             Expires July 31, 2010                 [Page 8]

Internet-Draft                    VALID                     January 2010


3.  Communication patterns

   The folllowing communication patterns are supported:

3.1.  In-band authentication

    __________                            _____________
   |          |                          |             |
   | End-user |------------------------->| Application |
   |__________|  1. Access application   |_____________|
                                                |        \
                                                |         |
                           2. Obtain assertion  |          > VALID
                                                |         |
                                          _____\|/____   /
                                         |            |
                                         | Validation |
                                         |   server   |
                                         |____________|



                          In-band authentication

   The end-user accesses the application (1).  The application supplies
   the authentication data to the validation server and receives an
   assertion in return (2).

   For in-band challenge/response authentication mechanisms, additional
   messages between the end-user and the validation server MUST be
   relayed by the application.

3.1.1.  In-band Challenge/Response


















Hoyer, et al.             Expires July 31, 2010                 [Page 9]

Internet-Draft                    VALID                     January 2010


       __________                            _____________
      |          |                          |             |
      | End-user |------------------------->| Application |
      |__________|  1. Access application   |_____________|
                    4. In-band challenge          /|\        \
                    5. In-band response            |         |
                             2. Request assertion  |          > VALID
                              3. return challenge  |         |
                              6. obtain assertion  |         |
                                             _____\|/____   /
                                            |            |
                                            | Validation |
                                            |   server   |
                                            |____________|


                   Figure 1: In-band Challenge/Response

   The "in-band challenge/response" pattern is shown in Figure 1.  The
   application invokes the validation server (2).  The validation server
   returns a challenge (3).  The application passes the challenge to the
   end-user (4).  The end-user may or may not transform the challenge
   and sends the result to the validation server in-band (5).  The
   application supplies the authentication data to the validation server
   and receives an assertion in return (6).

3.1.2.  In-band 2 way Challenge/Response

       __________                                 _____________
      |          |                               |             |
      | End-user |------------------------------>| Application |
      |__________|  1. In-band client challenge  |_____________|
                    4. In-band server resp & challenge /|\     \
                    5. In-band client response          |       |
                            2. Request assertion        |        > VALID
                            3. return server resp &     |       |
                               server challenge         |       |
                              6. obtain assertion       |       |
                                                  _____\|/____ /
                                                 |            |
                                                 | Validation |
                                                 |   server   |
                                                 |____________|



                Figure 2: In-band 2 way Challenge/Response




Hoyer, et al.             Expires July 31, 2010                [Page 10]

Internet-Draft                    VALID                     January 2010


   The "In-band 2 way challenge/response" pattern is shown in Figure 2.
   This pattern is based on the In-band Challenge/Response pattern but
   authenticates both the server and the client.  The application
   receives an in-band client challenge (1).  The application invokes
   the validation server (2).  The validation server returns the
   response to the client challenge and a server challenge (3).  The
   application passes the server response and server challenge to the
   end-user (4).  The end-user may or may not transform the server
   challenge and after verifying the server response sends the result to
   the validation server in-band (5).  The application supplies the
   authentication data to the validation server and receives an
   assertion in return (6).

3.2.  Out-of-band challenge

        __________                        _____________
       |          |                      |             |
    -->| End-user |--------------------->| Application |
   |   |__________|   1. Access          |_____________|
   |                     application            |     \
   |                                            |      |
   |                  4. In-band                |      |
   |                     Response               |      |
   |                               2. Request   |      |
   |                                  assertion |       >VALID
   | 3. Out-of-band                             |      |
   |    challenge                  5. Obtain    |      |
   |                                  assertion |      |
   |                                            |      |
   |                                      _____\|/____/
   |                                     |            |
   |                                     | Validation |
    -------------------------------------|   server   |
                                         |____________|



                           Out-of-band challenge

   The "out-of-band challenge" pattern is shown in Figure 2.  The
   application invokes the validation server (2).  The validation server
   then contacts the end-user out-of-band with a challenge (3).  The
   end-user may or may not transform the challenge and then passes it
   back to the application (4), which then passes it to the validation
   server and obtains an assertion in response (5).






Hoyer, et al.             Expires July 31, 2010                [Page 11]

Internet-Draft                    VALID                     January 2010


3.3.  Out-of-band response

        __________                        _____________
       |          |                      |             |
    ---| End-user |<-------------------->| Application |
   |   |__________|   1. Access          |_____________|
   |                     application           /|\     \
   |                                            |       |
   |                  4. In-band                |       |
   |                     challenge 2. Request   |       |
   |                                  assertion |       |
   | 5. Out-of-band                             |       |
   |    response                   3. Return    |        >VALID
   |                                  challenge |       |
   |                                            |       |
   |                               6. Send      |       |
   |                                  assertion |       |
   |                                            |       |
   |                                      _____\|/____ /
   |                                     |            |
   |                                     | Validation |
    ------------------------------------>|   server   |
                                         |____________|


                           Out-of-band response

   The "out-of-band response" pattern is shown in Figure 3.  The
   application invokes the validation server (2).  The validation server
   returns a challenge (3).  The application passes the challenge to the
   end-user (4).  The end-user may or may not transform the challenge
   and sends the result to the validation server out-of-band (5).  The
   validation server sends the assertion to the application (6).


















Hoyer, et al.             Expires July 31, 2010                [Page 12]

Internet-Draft                    VALID                     January 2010


3.4.  Client supplies challenge

        __________                       _____________
       |          |                     |             |
    -->| End-user |-------------------->| Application |
   |   |__________|  2. Supply          |_____________|
   |                    challenge              |      \
   |                    and response           |       |
   |                                           |       |
   |                              3. Obtain    |       |
   |                                 assertion |       |
   |    1. Obtain                              |        >VALID
   |       challenge                           |       |
   |                                           |       |
   |                                           |       |
   |                                           |       |
   |                                     _____\|/____ /
   |                                    |            |
   |                                    | Validation |
    ------------------------------------|   server   |
                                        |____________|



                         Client supplies challenge

   The "client supplies challenge" pattern is shown in Figure 4.  The
   end-user obtains a challenge out-of-band (1), calculates the response
   and send both challenge and response to the application (2).  The
   application then uses the challenge and response to obtain an
   assertion from the validation server (3).

3.5.  End-user obtains assertions Out-of-band from server

    __________                            _____________
   |          |                          |             |
   | End-user |------------------------->| Application |
   |__________|  2. Access application   |_____________|
      /    |        (passing assertion)
     |V    |
     |A    |
     |L    |
     |I    |                              ____________
     |D    |     1. Obtain assertion     |            |
     |      ---------------------------->| Validation |
      \                                  |   server   |
                                         |____________|




Hoyer, et al.             Expires July 31, 2010                [Page 13]

Internet-Draft                    VALID                     January 2010


                  Out-of-band from server authentication

   The End-user obtains the assertion directly or though a proxy from
   the validation server (1) then passes the assertion to the
   Application for authentication (2).














































Hoyer, et al.             Expires July 31, 2010                [Page 14]

Internet-Draft                    VALID                     January 2010


4.  Asynchronous communication

   The out-of-band communication patterns (Section 3.2 and Section 3.3)
   require asynchronous behavior, so that the application thread is not
   blocked while the challenge is being processed by the end-user.

4.1.  Out-of-band challenge

   In the case of the "out-of-band challenge" pattern (Section 3.2), the
   validation server SHALL return an <env:Body/env:Fault> element with
   the value:

      valid:Pending

   The validation server, upon sending this value, and the application,
   upon receiving it, SHALL terminate the current session.

   Once the application receives the response from the end-user, it
   SHALL initiate a new session with the validation server.

4.2.  Out-of-band response

   In the case of the "out-of-band response" pattern (Section 3.3), the
   validation server SHALL return an <env:Body/env:Fault> element with
   the value:

      valid:Pending

   The validation server, upon sending this value, and the application,
   upon receiving it, SHALL terminate the current session.

   Both parties MUST maintain the <wst:RequestSecurityToken/@Context>
   attribute as metadata associated with the initial session.  In the
   subsequent session, they MUST use this <wst:RequestSecurityToken/@
   Context> attribute value to correlate the challenge and response.
















Hoyer, et al.             Expires July 31, 2010                [Page 15]

Internet-Draft                    VALID                     January 2010


5.  User centric and device centric (pseudonymous) authentication models

   There are two authentication models supported by this specification:

5.1.  User Centric authentication model

   In this model the mapping between a specific user and the devices
   that belong to the specific user is known and managed by the
   validation server.  This means that the authentication request will
   contain explicit user information in form of a UserId

5.2.  Device Centric authentication model

   In this model the validation server does not have any knowledge to
   whom a specific device belongs.  The user-device mapping will be at
   the appllication or service provider.  This means that the
   authentication request MUST NOT contain uer information and that it
   MUST contain information to uniquely identify the device by using the
   <DeviceInfo> element as defined in [PSKC].
































Hoyer, et al.             Expires July 31, 2010                [Page 16]

Internet-Draft                    VALID                     January 2010


6.  Authentication moving factor resync

   Some authentication schemes gradually lose synchronization between
   client and server.  In order to compensate for this, the server must
   accept authentication data values within a range, or window of the
   moving factor (e.g. the event counter used in event based one time
   password algorithms, see [HOTP]).  When an authentication moving
   factor drifts to the edge of, or beyond, the server's window for a
   particular end-user, the server has to adjust its window.  This
   process is known as resyncing.

   Resyncing erodes assurance in the authentication event.  So,
   following a resync event, the validation server commonly requests a
   second authentication data value, which effectively restores the
   level of assurance provided by the authentication.

   The following two approaches to resyncing exist:

6.1.  Automatic re-sync based on authentication data

   In this approach, the resynchronisation is based only on the
   authentication data.  In this apporach the server searches through an
   extended window of the moving factor(s) to see if it can match the
   presented authentication data.  In this apporach two OTPs MUST be
   transmitted so that the server MUST try to match the first OTP with
   the extended window and also MUST match the second OTP with a normal
   window.

6.2.  Manual re-sync based on presenting moving factor values

   In this approach to resynchronisation, the server is given the exact
   value of the moving factor (e.g. the event counter value in [HOTP])
   together with the OTP.  The server MUST only set the moving factor(s)
   to the received value if the OTP matches successfully (given the new
   moving factor values).
















Hoyer, et al.             Expires July 31, 2010                [Page 17]

Internet-Draft                    VALID                     January 2010


7.  Policy models

   Authentication policy defines the requirements for accessing a
   resource in terms of mechanisms and their strengths, expressible in
   disjunctive normal form (that is a disjunction ("OR") of conjunctions
   ("AND"s)).  This approach supports risk-based multi-factor
   authentication.

   Two policy models are supported.  In the first model (see figuer
   below), the application is responsible for invoking the right
   combination of validation servers in order to satisfy the
   authentication policy.

                  _____________
                 |             |
                 | Application |
                 |_____________|
                        |                      \
           _____________|______________         |
          |             |              |         > VALID
          |             |              |        |
    ______|_____   _____|______   _____|______ /
   |            | |            | |            |
   | Validation | | Validation | | Validation |
   |   server   | |   server   | |   server   |
   |____________| |____________| |____________|


                         Policy aware application

   In the second model (see figure below), the authentication policy is
   managed through a choreography component, which appears to the
   application as a validation server and to the validation server as an
   application.

















Hoyer, et al.             Expires July 31, 2010                [Page 18]

Internet-Draft                    VALID                     January 2010


                  _____________
                 |             |
                 | Application |
                 |_____________|
                        |                     \
                        |                      |
                        |                       >VALID
                        |                      |
                  ______|_______              /
                 |              |
                 | Choreography |
                 |______________|
                        |                     \
          ______________|______________        |
         |              |              |        >VALID
         |              |              |       |
    _____|______   _____|______   _____|______/
   |            | |            | |            |
   | Validation | | Validation | | Validation |
   |   server   | |   server   | |   server   |
   |____________| |____________| |____________|


                         Policy aware application

   In either model, the application MAY supply information about the
   resource to which access is requested in a <wsp:AppliesTo> element.
   The validation server MAY restrict the resources to which the
   application SHALL limit access by including a <wsp:AppliesTo> element
   in its response.  This is not intended as an access-control solution;
   it is intended only to enforce an appropriate level of authentication
   assurance, based on the sensitivity of the resource, where the
   sensitivity is not uniform across all the resources accessible by the
   application.

















Hoyer, et al.             Expires July 31, 2010                [Page 19]

Internet-Draft                    VALID                     January 2010


8.  Common message contents

   This section describes the mechanism-independent requirements for
   message contents.

8.1.  Request Security Token

   The message-independent requirements for "request security token"
   messages are shown in this example:

<wst:RequestSecurityToken Context=" ... ">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
</wst:RequestSecurityToken>

   <wst:TokenType> - MANDATORY  The client SHALL set the value 'http://
      docs.oasis-open.org/wss/
      oasis-wss-saml-token-profile-1.1#SAMLV2.0'.  If the server detects
      a different value it MAY return a fault.

   <wst:RequestType> - MANDATORY  The client SHALL set the value
      'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If
      the server detects a different value it SHALL return a fault.

   <wsp:AppliesTo> - OPTIONAL  If present, the client MUST set the value
      to a URI identifying the resource, or class of resource, to which
      access is requested.  If the validation server is policy-aware, it
      SHOULD use this value to select the applicable authentication
      policy.  Otherwise, it MUST ignore it.

   <wsp:Policy/saml:Attribute> - OPTIONAL  If present, this element MUST
      identify a verified end-user attribute requested from the
      validation server.  Even if the validation server cannot provide
      all the requested attributes, it SHOULD proceed with the
      validation process.







Hoyer, et al.             Expires July 31, 2010                [Page 20]

Internet-Draft                    VALID                     January 2010


   <wst:Lifetime> - OPTIONAL  The client MAY specify the lifetime of the
      requested assertion using this element.  The server MUST verify
      that the requested lifetime conforms with its own policy for
      assertion lifetimes.

   <wst:RequestSecurityToken/@Context> - MANDATORY  This attribute MUST
      be set by the client.  It is an opaque value to the server.  The
      server MUST use the value as the <wst:RequestSecurityToken/@
      Context> value in the response.

8.2.  Request Security Token Response

   The common requirements for the final "request security token
   response" message are shown in this example:

   <wst:RequestSecurityTokenResponse Context=" ... ">
       <wst:RequestedSecurityToken>
             ...
       </wst:RequestedSecurityToken>
       <wst:Claims Dialect="...">
           <saml:Attribute/> +
       </wst:Claims> ?
       <wsp:AppliesTo> ... </wsp:AppliesTo> ?
       <wsp:Policy> ?
           <wsp:RequiredElement> +
       </wsp:Policy>
   </wst:RequestSecurityTokenResponse>

   If the authentication data failed to validate, then the server MUST
   include the <env:Body/env:Fault> element containing the value wst:
   FailedAuthentication.  In this case, it SHALL NOT include any other
   elements.

   If the authentication data failed to validate due to missing
   authentication data, then the server MUST include the <env:Body/
   env:Fault> element containing the value valid:
   MissingAuthenticationData.  The server can optionally include
   elements indicating which authentication data is missing.

   <wst:RequestedSecurityToken> - OPTIONAL - Zero or more  If validation
      is complete and successful, then the server SHALL include a SAML
      assertion containing verified end-user attributes.  Otherwise this
      element SHALL be omitted.  The server SHOULD set the assertion
      lifetime in accordance with the lifetime specified in the request,
      or its own policy, whichever is more restrictive.






Hoyer, et al.             Expires July 31, 2010                [Page 21]

Internet-Draft                    VALID                     January 2010


   <wst:RequestType> - MANDATORY  The client SHALL set the value
      'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If
      the server detects a different value it SHALL return a fault.

   <wst:Claims> - OPTIONAL  If present, the server SHALL populate this
      element with verified end-user attributes.

   <wst:Claims/@Dialect> - OPTIONAL  The server SHALL set the value
      "urn:oasis:names:tc:SAML:2.0".  The client MAY reject responses
      containing a different value.

   <wpt:AppliesTo> - OPTIONAL  If the authentication assurance level
      achieved is suitable only for a sub-set of resources, the
      validation server MUST set a value that identifies that sub-
      set.The client SHOULD restrict access to resources falling within
      the sub-set defined by this element.

   <wst:RequestSecurityToken/@Context> - MANDATORY  The server MUST
      include the @Context value from the request.  The client SHOULD
      load the context identified by the value.































Hoyer, et al.             Expires July 31, 2010                [Page 22]

Internet-Draft                    VALID                     January 2010


9.  Mechanism-specific message contents

   The mechanism-specific requirements for message contents are
   described in the appendices.  These MAY be used in any combination.















































Hoyer, et al.             Expires July 31, 2010                [Page 23]

Internet-Draft                    VALID                     January 2010


10.  Extensibility

   This section lists a few common extension points provided by VALID:

   New VALID Version:  Whenever it is necessary to define a new version
      of this document then a new version number has to be allocated to
      refer to the new specification version.  The rules for
      extensibililty are defined in Section 11.











































Hoyer, et al.             Expires July 31, 2010                [Page 24]

Internet-Draft                    VALID                     January 2010


11.  IANA Considerations

11.1.  XML namespace registration

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:valid", per the guidelines in [RFC3688].

   URI:  urn:ietf:params:xml:ns:valid

   Registrant Contact:  Philip Hoyer (phoyer@actividentity.com).

   XML:

   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
     <title>VALID Namespace</title>
   </head>
   <body>
     <h1>Namespace for VALID</h1>
     <h2>urn:ietf:params:xml:ns:valid</h2>
   <p>See <a href="[URL of published RFC]">RFCXXXX
       [NOTE TO IANA/RFC-EDITOR:
        Please replace XXXX with the RFC number of this
       specification.]</a>.</p>
   </body>
   </html>
   END

11.2.  VALID Version Registry

   IANA is requested to create a registry for VALID version numbers.
   The registry has the following structure:

     VALID Version              | Specification
   +---------------------------+----------------
   | 1.0                       | [This document]

   Standards action is required to define new versions of VALID.  It is
   not envisioned to depreciate, delete, or modify existing VALID
   versions.





Hoyer, et al.             Expires July 31, 2010                [Page 25]

Internet-Draft                    VALID                     January 2010


12.  Security Considerations

   The validation server SHOULD authenticate the client and limit access
   to the validation service only to authorized clients.  This MAY be
   achieved by object level security (e.g xml signatures as defined in
   [XMLDSIG] applied to the <env:Header> and <env:Body> elements),
   transport layer security (e.g.  [TLS]) or network layer security
   (e.g. isolated network segment).

   The application MAY authenticate the validation server.  This MAY be
   achieved by object level security (e.g. xml signatures as defined in
   [XMLDSIG] applied to the <env:Header> and <env:Body> elements or
   assertion), transport layer security (e.g.  TLS) or network layer
   security (e.g. isolated network segment).

   The chosen authentication mechanism MUST ensure freshness of the
   exchanges in order to detect replay attacks.

   Privacy of the authentication data and end-user attributes MAY also
   require protection.































Hoyer, et al.             Expires July 31, 2010                [Page 26]

Internet-Draft                    VALID                     January 2010


13.  Acknowledgements

   The authors of this draft would like to thank the following people
   for their feedback: Siddharth Bajaj, David M'Raihi, Mike Davis and
   Peter Tapling.

   This work is based on earlier work by the members of OATH (Initiative
   for Open AuTHentication), see [OATH], to specify a format that can be
   freely distributed to the technical community.










































Hoyer, et al.             Expires July 31, 2010                [Page 27]

Internet-Draft                    VALID                     January 2010


14.  References

14.1.  Normative References

   [RFC2119]  "Key words for use in RFCs to Indicate Requirement
              Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [SAML]     Cantor, S., Kemp, J., Philpott, R., and E. Maler, "WS-
              Trust 1.4", URL: http://docs.oasis-open.org/security/saml/
              v2.0/saml-core-2.0-os.pdf, OASIS Standard Specification,
              March 2005.

   [SOAP]     Gudgin, M., "Simple Object Access Protocol 1.2",
              URL: http://www.w3.org/TR/soap12-part1/,
              W3C Recommendation, April 2007.

   [WS-Security]
              Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker,
              "Web Services Security: SOAP Message Security 1.1", URL:
               http://www.oasis-open.org/committees/download.php/16790/
              wss-v1.1-spec-os-SOAPMessageSecurity.pdf, OASIS Standard
              Specification, Feb 2006.

   [WS-Trust]
              Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H.
              Granqvist, "WS-Trust 1.4", URL: http://
              docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html,
              OASIS Standard Specification, Feb 2009.

   [WSS_UsernameTokenProfile]
              Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker,
              "Web Services Security UsernameToken Profile 1.1", URL:
               http://docs.oasis-open.org/wss/v1.1/
              wss-v1.1-spec-os-UsernameTokenProfile.pdf, OASIS Standard
              Specification, Feb 2006.

   [XMLDSIG]  Eastlake, D., "XML-Signature Syntax and Processing",
              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
              W3C Recommendation, February 2002.



Hoyer, et al.             Expires July 31, 2010                [Page 28]

Internet-Draft                    VALID                     January 2010


   [XMLENC]   Eastlake, D., "XML Encryption Syntax and Processing.",
              URL: http://www.w3.org/TR/xmlenc-core/,
              W3C Recommendation, December 2002.

14.2.  Informative References

   [HOTP]     MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226, December 2005.

   [OATH]     "Initiative for Open AuTHentication",
              URL: http://www.openauthentication.org.

   [OCRA]     MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S.
              Bhajaj, "OCRA: OATH Challenge-Response Algorithms", URL:
               http://docs.oasis-open.org/security/saml/v2.0/
              saml-core-2.0-os.pdf, IETF Standard draft, January 2008.

   [PSKC]     Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
              Key Container (PSKC)",
              URL: http://tools.ietf.org/html/
              draft-ietf-keyprov-pskc-05, IETF Standard draft,
              January 2010.

   [RFC2396]  Berners-Lee, T., Berners-Lee, T., Fielding, R., and L.
              Masinter, "Uniform Resource Identifiers (URI): Generic
              Syntax", BCP 26, RFC 2396, August 1998.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [XMLNS]    "Namespaces in XML", W3C Recommendation ,
              URL: http://www.w3.org/TR/1999/REC-xml-names-19990114,
              January 1999.
















Hoyer, et al.             Expires July 31, 2010                [Page 29]

Internet-Draft                    VALID                     January 2010


Appendix A.  WSDL

   The validation server WSDL is shown here.

 <?xml version="1.0" encoding="utf-8"?>
 <definitions targetNamespace="urn:ietf:params:xml:ns:valid"
 xmlns:valid="urn:ietf:params:xml:ns:valid"
 xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wss="http://docs.oasis-open.org/wss/2004/01/
 oasis-200401-wss-wssecurity-secext-1.0"
 xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
 xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"
 xmlns:wsp="http://www.w3.org/ns/ws-policy"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
   <xsd:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:valid="urn:ietf:params:xml:ns:valid"
   xmlns:wss="http://docs.oasis-open.org/wss/2004/01/
   oasis-200401-wss-wssecurity-secext-1.0"
   xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
   xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"
   xmlns:wsp="http://www.w3.org/ns/ws-policy"
   xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/"
   targetNamespace="urn:ietf:params:xml:ns:valid"
   elementFormDefault="unqualified"
   attributeFormDefault="unqualified">
    <xsd:element name="RequestSecurityToken"
    type="wst:RequestSecurityTokenType"/>
    <xsd:element name="RequestSecurityTokenResponse"
    type="wst:RequestSecurityTokenResponseType"/>
    <xsd:element name="OTP" type="xsd:string"/>
    <xsd:element name="NextOTP" type="xsd:string"/>
    <xsd:element name="SyncCounter" type="xsd:integer"/>
    <xsd:element name="SyncTime" type="xsd:integer"/>
    <xsd:element name="KeyId" type="pskc:string"/>
    <xsd:element name="DeviceInfo" type="pskc:DeviceInfo"/>
   </xsd:schema>
  </types>
  <message name="RequestSecurityToken">
   <part name="request" element="valid:RequestSecurityToken"/>
  </message>
  <message name="RequestSecurityTokenResponse">
   <part name="response" element="valid:RequestSecurityTokenResponse"/>



Hoyer, et al.             Expires July 31, 2010                [Page 30]

Internet-Draft                    VALID                     January 2010


  </message>
  <portType name="RequestSecurityToken">
   <operation name="RequestSecurityTokenStart">
    <input message="RequestSecurityToken"/>
    <output message="RequestSecurityTokenResponse"/>
   </operation>
   <operation name="RequestSecurityTokenContinue">
    <input message="RequestSecurityTokenResponse"/>
    <output message="RequestSecurityTokenResponse"/>
   </operation>
  </portType>
  <binding name="RequestSecurityTokenBinding"
  type="valid:RequestSecurityToken">
   <SOAP:binding style="rpc"
   transport="http://schemas.xmlsoap.org/soap/http"/>
   <operation name="RequestSecurityTokenStart">
    <SOAP:operation style="rpc"/>
    <input>
     <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
    </input>
    <output>
     <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
    </output>
   </operation>
   <operation name="RequestSecurityTokenContinue">
    <SOAP:operation style="rpc"/>
    <input>
     <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
    </input>
    <output>
     <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/>
    </output>
   </operation>
  </binding>
  <service name="RequestSecurityToken">
   <port name="RequestSecurityTokenStart"
   binding="RequestSecurityTokenBinding">
    <SOAP:address
    location="http://localhost:8080/RequestSecurityTokenService"/>
   </port>
   <port name="RequestSecurityTokenContinue"
   binding="RequestSecurityTokenBinding">
    <SOAP:address
    location="http://localhost:8080/RequestSecurityTokenService"/>
   </port>
  </service>
 </definitions>




Hoyer, et al.             Expires July 31, 2010                [Page 31]

Internet-Draft                    VALID                     January 2010


Appendix B.  Mechanism specific message contents

   The follwing subsections describe the mechanism specific message
   contents for each considered mechanism:

B.1.  Username/password

   This section describes the mechanism-specific message contents
   username/password transferred in-band.  There are no semantics
   implied by the order of the elements.  The username and password
   transmission uses the web services security Username Token Profile
   [WSS_UsernameTokenProfile].

   There are two steps to the protocol.

   Step 1 - Client sends "request security token" message containing
   authentication data to the validation server.

 <wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username> ?
        <wss:Password Type="...">Password</wss:Password>
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   <wst:RequestSecuityToken/wss:UsernameToken/wss:Username>  If present,
      the client MUST set the value to the claimed username.  The server
      MUST load the corresponding end-user record.  Either the <wss:
      Username> element or the <valid:KeyId> element or both MUST be
      present.

   <wst:RequestSecuityToken/wss:UsernameToken/wss:Password>  The client
      MUST set the value to password entered by the end user.  The
      server MUST validate the password.

   The server MUST confirm that all the supplied authentication data are
   valid for a single end-user.



Hoyer, et al.             Expires July 31, 2010                [Page 32]

Internet-Draft                    VALID                     January 2010


   Step 2 - Validation server sends "request security token response"
   message containing the authentication result to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

B.2.  In band one-time-password (OTP)

   This section describes the mechanism-specific message contents for
   both time-based and event-based OTP protocols in which the OTP is
   transferred in-band.  There are no semantics implied by the order of
   the elements.

   There are two steps to the protocol.

   Step 1 - Client sends "request security token" message containing
   authentication data to the validation server.

 <wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username> ?
        <valid:KeyId> ... </valid:KeyId> ?
        <pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
        <valid:OTP> ... </valid:OTP>
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   <wst:RequestSecuityToken/wss:UsernameToken/wss:Username>  If present,
      the client MUST set the value to the claimed username.  The server
      MUST load the corresponding end-user record.  Either the <wss:
      Username> element or the <valid:KeyId> element or both MUST be
      present.




Hoyer, et al.             Expires July 31, 2010                [Page 33]

Internet-Draft                    VALID                     January 2010


   <wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId>  If present,
      the client MUST set the value to the KeyId of the key used for OTP
      computations.  The server MUST load the corresponding key record..

   <wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo>  If
      present, the client MUST set the subelement values of pskc:
      DeviceInfo as defined in [PSKC] to value that uniuquely identify
      the device used for OTP computations.  The server MUST load the
      corresponding device record..

   <wst:RequestSecuityToken/wss:Security/valid:OTP>  The client MUST set
      the value to the OTP value.  The server MUST validate the OTP.

   The server MUST confirm that all the supplied authentication data are
   valid for a single end-user.

   Step 2 - Validation server sends "request security token response"
   message containing the authentication result to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

   The following authentication data are defined by this specification.

      Name: valid:OTP

      Type: xsd:string

      Description: The output value of an end-user OTP token

      Name: valid:KeyId

      Type: xsd:string

      Description: The globally-unique identifier for key used in the
      OTP computation

      Name: pskc:DeviceInfo

      Type: pskc:DeviceInfo

      Description: A extensible element to uniquely identify devices
      used in OTP computations as defined in [PSKC].




Hoyer, et al.             Expires July 31, 2010                [Page 34]

Internet-Draft                    VALID                     January 2010


B.3.  In band one-time-password (OTP) token synchronization

   This section describes the mechanism-specific message contents for
   both time-based, event-based and time-event based OTP algorithms in
   which resynchronization data is sent in-band.

   Synchronization can happen either by sending two subsequqnt OTPs from
   the device or by sending only one OTP and the exact values of one or
   multiple moving factors (e.g.Counter, TIme, etc) used in the OTP
   algorithm.

   There are two steps to the protocol.

   Step 1 - Client sends "request security token" message containing
   synchronization data to the validation server.

 <wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
urn:ietf:params:xml:ns:valid#synchronization
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username> ?
        <valid:KeyId> ... </valid:KeyId> ?
        <pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
        <valid:OTP> ... </valid:OTP>
        <valid:NextOTP> ... </valid:NextOTP>?
        <valid:SyncCounter> ... </valid:SyncCounter>?
        <valid:SyncTimer> ... </valid:SyncTime>?
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   <wst:RequestSecuityToken/wss:UsernameToken/wss:Username>  If present,
      the client MUST set the value to the claimed username.  The server
      MUST load the corresponding end-user record.  Either the <wss:
      Username> element or the <valid:KeyId> element or both MUST be
      present.







Hoyer, et al.             Expires July 31, 2010                [Page 35]

Internet-Draft                    VALID                     January 2010


   <wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId>  If present,
      the client MUST set the value to the KeyId of the key used for OTP
      computations.  The server MUST load the corresponding key record..

   <wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo>  If
      present, the client MUST set the subelement values of pskc:
      DeviceInfo as defined in [PSKC] to value that uniuquely identify
      the device used for OTP computations.  The server MUST load the
      corresponding device record..

   <wst:RequestSecuityToken/wss:Security/valid:OTP>  The client MUST set
      the value to the OTP value.  The server MUST validate the OTP
      within an extended synchronization window.

   <wst:RequestSecuityToken/wss:Security/valid:NextOTP>  If present, the
      client MUST set this value to the next OTP value obtained from the
      OTP device.  The server MUST validate this OTP within a normal
      validation window upon successful validation of the first OTP.

   <wst:RequestSecuityToken/wss:Security/valid:SyncCounter>  If present,
      the client MUST set the value to the current OTP Counter moving
      factor from the claimed device.  The server MUST validate that the
      given OTP corresponds to the given value in <valid:SyncCounter>
      and then set the Counter moving factor value to its own record for
      the claimed token.

   <wst:RequestSecuityToken/wss:Security/valid:SyncTime>  If present,
      the client MUST set the value to the current OTP Time moving
      factor from the claimed device.  The server MUST validate that the
      given OTP corresponds to the given value in <valid:SyncTime> and
      then set the Time moving factor value to its own record for the
      claimed token.

   The server MUST confirm that all the supplied synchronization data
   are valid and adjust its token record with the validated client data.

   Step 2 - Validation server sends "request security token response"
   message containing the synchronization result to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

   The following synchronization data are defined by this specification.




Hoyer, et al.             Expires July 31, 2010                [Page 36]

Internet-Draft                    VALID                     January 2010


      Name: valid:OTP

      Type: xsd:string

      Description: The output value of an end-user OTP token

      Name: valid:NextOTP

      Type: xsd:string

      Description: The output value of an end-user OTP token for the
      next consecutive OTP

      Name: valid:MovingFactor

      Type: xsd:integer

      Description: The current OTP moving factor in a client token.  It
      is the event counter for an event based token, for example, HOTP.

      Name: valid:KeyId

      Type: xsd:string

      Description: The globally-unique identifier for the OTP token

B.4.  In band challenge/response

   This appendix describes the mechanism-specific message contents for
   challenge/response authentication mechanisms in which both the
   challenge and response are transferred in-band.  Mechanisms of this
   type include: knowledge-based schemes, matrix card schemes and
   cryptographic token schemes.  There are no semantics implied by the
   order of the elements.

   There are four steps to the protocol.

   Step 1 - Client sends "request security token" message containingthe
   claimed identity to the validation server.












Hoyer, et al.             Expires July 31, 2010                [Page 37]

Internet-Draft                    VALID                     January 2010


 <wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username> ?
        <valid:KeyId> ... </valid:KeyId> ?
        <pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   Step 2 - Validation server sends "request security token response"
   message containing the challenge to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallenge>
           ...
       </wst14:InteractiveChallenge>
   </wst:RequestSecurityTokenResponse>

   <wst:RequestSecurityTokenResponse/wst14:InteractiveChallenge>  The
      server MUST set the contents to the value of the challenge.

   Step 3 - Client sends "request security token response" message
   containing the response to the server.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallengeResponse>
           ...
       </wst14:InteractiveChallengeResponse>
   </wst:RequestSecurityTokenResponse>

   <wst:RequestSecurityTokenReponse/wst14:InteractiveChallengeResponse>
      The client MUST set the value to the transformed challenge.  The
      server MUST validate the transformed challenge.

   Step 4 - Server sends "request security token response" message
   containing the authentication result to the client.





Hoyer, et al.             Expires July 31, 2010                [Page 38]

Internet-Draft                    VALID                     January 2010


   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

B.5.  Out-of-band challenge

   This appendix describes the mechanism-specific message contents for
   challenge/response mechanisms in which the challenge is passed to the
   end-user out-of-band.  Such mechanisms involve a separate
   communication channel, such as voice telephone, email or SMS.  There
   are no semantics implied by the order of the elements.

   There are four steps to the protocol.

   Step 1 - Client sends "request security token" message containing
   claimed identity to the server.

<wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username>
        <valid:KeyId> ... </valid:KeyId> ?
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   Step 2 - (Optional, in the asynchronous case) Server sends "pending"
   to the client.

   <env:Body/env:Fault>
           valid:Pending
   </env:Body/env:Fault>

   Both the client and server close the session.

   Step 3 - Once the client receives the response, it sends the "request



Hoyer, et al.             Expires July 31, 2010                [Page 39]

Internet-Draft                    VALID                     January 2010


   security token response" message to the server..

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallengeResponse>
           ...
       </wst14:InteractiveChallengeResponse>
   </wst:RequestSecurityTokenResponse>

   Step 4 - Server sends "request security token response" message
   containing the authentication result to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

   The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST
   be the same as that used in steps 1, 2 and 3.

B.6.  Out-of-band response

   This appendix describes the mechanism-specific message contents for
   challenge/response mechanisms in which the response is returned to
   the validation server out-of-band.  Such mechanisms involve a
   separate communication channel, such as voice telephone, email or
   SMS.  There are no semantics implied by the order of the elements.

   There are four steps to the protocol.

   Step 1 - Client sends "request security token" message containing the
   claimed identity to the server.


















Hoyer, et al.             Expires July 31, 2010                [Page 40]

Internet-Draft                    VALID                     January 2010


<wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username>
        <valid:KeyId> ... </valid:KeyId> ?
        <pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   Step 2 - Server sends "request security token response" message
   containing the challenge to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallenge>
           ...
       </wst14:InteractiveChallenge>
   </wst:RequestSecurityTokenResponse>

   Step 3 - (Optional - in the asynchronous case) Client sends "pending"
   to the server.

   <env:Body/env:Fault>
           valid:Pending
   </env:Body/env:Fault>

   Both the client and server close the session.

   Step 4 - Server sends "request security token response" message
   containing the authentication result to the client at the registered
   call-back interface.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>




Hoyer, et al.             Expires July 31, 2010                [Page 41]

Internet-Draft                    VALID                     January 2010


   The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST
   be the same as that used in steps 1, 2 and 3.

B.7.  Client supplies challenge

   This appendix describes the mechanism-specific message contents for
   challenge/response mechanisms in which the client supplies the
   challenge.  There are no semantics implied by the order of the
   elements.

   There are two steps to the protocol.

   Step 1 - Client sends "request security token" message to the
   validation server, passing both the challenge and the response.

<wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wst14:InteractiveChallenge> ...
    </ wst14:InteractiveChallenge>
    <wst14:InteractiveChallengeResponse> ...
    </ wst14:InteractiveChallengeResponse>
</wst:RequestSecurityToken>

   <wst14:InteractiveChallenge>  The challenge.  This may have been
      obtained from the validation server by means of another interface;
      one not specified here.

   <wst14:InteractiveChallengeResponse>  The client MUST set the value
      to the transformed challenge.  The server MUST validate the
      transformed challenge.

   Step 2 - Validation server returns "request security token response"
   message containing the assertion and claims to the client.








Hoyer, et al.             Expires July 31, 2010                [Page 42]

Internet-Draft                    VALID                     January 2010


   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

B.8.  Challenge/response with signature

   This appendix describes the mechanism-specific message contents for
   challenge/response authentication mechanisms in which both the
   challenge and response are transferred in-band additionally to other
   parameters that are used in a signature (such as the simmetric
   signature in [OCRA].  There are no semantics implied by the order of
   the elements.

   There are four steps to the protocol.

   Step 1 - Client sends "request security token" message containingthe
   claimed identity to the validation server.

 <wst:RequestSecurityToken Context="...">
    <wst:TokenType>
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
    </wst:TokenType>
    <wst:RequestType>
http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
    </wst:RequestType>
    <wsp:AppliesTo> ... </wsp:AppliesTo> ?
    <wsp:Policy> ?
        <saml:Attribute> +
    </wsp:Policy>
    <wst:Lifetime> ... </wst:Lifetime> ?
    <wss:UsernameToken>
        <wss:Username> ... </wss:Username> ?
        <valid:KeyId> ... </valid:KeyId> ?
        <pskc:DeviceInfo> ...</pskc:DeviceInfo> ?
    </wss:UsernameToken>
</wst:RequestSecurityToken>

   Step 2 - Validation server sends "request security token response"
   message containing the set of challenges to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallenge> +
           ...
       </wst14:InteractiveChallenge>
   </wst:RequestSecurityTokenResponse>



Hoyer, et al.             Expires July 31, 2010                [Page 43]

Internet-Draft                    VALID                     January 2010


   <wst:RequestSecurityTokenResponse/wst14:InteractiveChallenge>  The
      server MUST set the contents to the value of the challenge(s).

   Step 3 - Client sends "request security token response" message
   containing the response(s) to the server.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst14:InteractiveChallengeResponse> +
           ...
       </wst14:InteractiveChallengeResponse>
   </wst:RequestSecurityTokenResponse>

   <wst:RequestSecurityTokenReponse/wst14:InteractiveChallengeResponse>
      The client MUST set the value to the parameters of the signature
      (e.g. amount is set to '10000').  The server MUST validate the
      transformed challenge.

   Step 4 - Server sends "request security token response" message
   containing the authentication result to the client.

   <wst:RequestSecurityTokenResponse Context="...">
       <wst:RequestedSecurityToken>
           <saml:Assertion> ... </saml:Assertion>
       </wst:RequestedSecurityToken>
       <wst:Claims> ... </wst:Claims>
   </wst:RequestSecurityTokenResponse>

























Hoyer, et al.             Expires July 31, 2010                [Page 44]

Internet-Draft                    VALID                     January 2010


Appendix C.  Use Cases

   This section describes a comprehensive list of use cases that
   inspired the development of this specification.  These requirements
   were used to derive the primary requirement that drove the design.
   These requirements are covered in the next section.

   These use cases also help in understanding the applicability of this
   specification to real world situations.

C.1.  Validation

C.1.1.  OTP Validation

   An application needs to validate an OTP obtained from an end-user,
   before providing the end-user with access to the requested
   resource(s).  The validation request may pass through several SOAP
   intermediaries.  If this is the case, the application message needs
   to specify the ultimate validation server endpoint via SOAP
   addressing means, e.g., by using SOAP actors, to avoid the OTP being
   evaluated several times.  The response may include additional
   instructions to the token, for example that it needs to be
   resynchronized.  This information must be defined inside a SOAP
   message.

   Valid credentials that can be passed in the valildation request:

   o  Username, PIN + OTP

   o  Username, OTP

   o  TokenId + OTP

   o  Array of TokenId + OTP

C.1.2.  Challenge/Response Validation - Server generated challenge

   An application needs to be able to use a token implementing the OCRA
   challenge/response algorithm for identifying the end user.  The
   application requests from the validation server the challenge to be
   presented to the token (with the end-user keying the challenge into
   the token by means of a PINPad) or the challenge presented to the API
   of the connected token The application then uses the protocol to
   verify the response from the token







Hoyer, et al.             Expires July 31, 2010                [Page 45]

Internet-Draft                    VALID                     January 2010


C.1.3.  Challenge/Response Validation - User generated challenge

   An application needs to be able to use a token implementing the OCRA
   challenge/response algorithm for identifying the end user.  The
   application generates the challenge to be presented to the token
   (with the end-user keying the challenge into the token by means of a
   PINPad) or the challenge presented to the API of the connected token
   The application then uses the protocol to verify the challenge and
   the response from the token.

C.1.4.  2-way mutual Challenge/Response Validation

   An application needs to be able to use a token implementing the OCRA
   2 way challenge/response algorithm for identifying the end user and
   the user will identify the validation server.  A connected token
   generates a client challenge and trasnmits it to the appllication,
   the application will accept the challenge and send it to the
   validation server, which will then return a server-response to the
   client challenge and a server challenge.  The connected token will
   verify the server response and after successfully validating the
   server response sends uses the server-challenge to generate a client-
   response which is sent to the appliaction.  The application then uses
   the protocol to verify the the response from the connected client.

C.1.5.  OTP Validation + Server managed PIN

   An application needs to be able to use a token implementing the TOTP
   algorithm as one factor and a server managed PIN as a second factor,
   for indetifying the end user.  The verification of both factors
   should occur within one message request/response pair of the
   protocol.

C.1.6.  MatrixCardValidation - Server generated challenge

   An application needs to be able to use MatrixCard challenge/response
   algorithm for identifying the end user.  The application will request
   from the validation server the challenge to be presented to the user
   via the user interface and the user response entered into a webform
   The application will then use the protocol to verify the response
   from the token

C.2.  Synchronisation Use Cases

   This section describes the use cases relating to synchronisation of
   the token and the server.






Hoyer, et al.             Expires July 31, 2010                [Page 46]

Internet-Draft                    VALID                     January 2010


C.2.1.  OTP Token Resync with the Next OTPs

   An application needs to validate an OTP but the OTP could not be
   validated because the OTP moving factor is out-of-sync between the
   token and the server.  The validation server detects that the given
   OTP corresponds to a future moving factor that falls in an acceptable
   re-sync window.  The application decides that a re-sync is necessary.
   It asks the next generated OTP from the token to re-sync the token.
   The validation server adjusts its record of the token's moving factor
   to the one that corresponds to the given OTP upon successful
   validation.  Two consecutive OTPs could also be directly used for a
   validation server to re-sync a token, where the server tries to match
   the first OTP with an extended synchronization window and then match
   the second OTP with a normal authentication window.

C.2.2.  OTP Token Resync with Moving Factor

   An application needs to validate an OTP but the OTP could not be
   validated because the OTP moving factor is out-of-sync between the
   token and the server.  The validation server detects that the given
   OTP corresponds to a future moving factor that falls in an acceptable
   re-sync window.  The application decides that a re-sync is necessary.
   It uses values that can be read by the user of the token (e.g. event
   counter value, time interval counter value) to re-sync the token
   together with the next generated OTP of the token.


























Hoyer, et al.             Expires July 31, 2010                [Page 47]

Internet-Draft                    VALID                     January 2010


Appendix D.  Requirements

   This section outlines the most relevant requirements that are the
   basis of this work.  Several of the requirements were derived from
   use cases described above.

   R1:  The protocol must support authentication of request originator.

   R2:  The protocol must support management data flows (e.g., related
        to token synchronization)

   R3:  The protocol needs to support the following algorithms

        *  HOTP

        *  OCRA

        *  TOTP

        *  Proprietary OTP

        *  Proprietary Challenge/Response

        *  Matrix cards

        *  SMS OTP

        *  PKI based challenge/response

   R4:  The protocol must be XML/Web Services based.

   R5:  The protocol must support SOAP intermediaries.



















Hoyer, et al.             Expires July 31, 2010                [Page 48]

Internet-Draft                    VALID                     January 2010


Authors' Addresses

   Philip Hoyer
   ActivIdentity, Inc.
   117 Waterloo Road
   London, SE1  8UL
   UK

   Phone: +44 (0) 20 7744 6455
   Email: phoyer@actividentity.com


   Tim Moses
   Entrust, Inc.
   1000 Innovation Drive
   Ottawa, Ontario  K2K 3E7
   Canada

   Phone: +1 (613) 270-3400
   Email: tim.mosesi@entrust.com


   Mingliang Pei
   VeriSign, Inc.
   487 E. Middlefield Road
   Mountain View, CA  94043
   USA

   Phone: +1 650 426 5173
   Email: mpei@verisign.com


   Salah Machani
   Diversinet, Inc.
   2225 Sheppard Avenue East
   Suite 1801
   Toronto, Ontario  M2J 5C2
   Canada

   Phone: +1 416 756 2324 Ext. 321
   Email: smachani@diversinet.com










Hoyer, et al.             Expires July 31, 2010                [Page 49]

