DSS Extension for Local Signature Computation Version 1.0

This use case assumes a thick or thin client platform. The (secure) signature-creation device can be a smartcard connected to the client platform by means of a smartcard reader. A web browser is used to let the end user access the web application. The web application has implemented the DSS protocol. To sign (a) document(s), the web application sends the document(s) to the DSS server; the DSS server must obtain (somehow) the digital signature value computed by the smartcard. Note that the DSS server cannot access the smartcard reader without additional mechanisms; proposals to solve this are presented in section Section 1.7.3, “Proposed Solutions”.

Figure 4. A smartcard connected to a desktop

This use case assumes the use of a mobile phone that contains a (secure) signature-creation device. The mobile phone is connected to the mobile operator infrastructure. A web browser is used to let the end user access the client application. The client application has implemented the DSS protocol. To sign (a) document(s), the client sends the document(s) to the DSS server; the DSS server must obtain the digital signature value computed by the smartcard in the mobile phone. The DSS server connects to the mobile phone which requests the user to sign (the provided digest).

This use case resembles the ETSI standard for Mobile Commerce (M-COMM) or Mobile Signature Service [M-COMM].

Figure 5. A mobile phone for signature creation

This use case assumes the use of a smartphone that contains a (secure) signature-creation device. The smartphone contains an app to sign (a) document(s), although the actual electronic signature processing functionality is delegated to a DSS server. The app has implemented the DSS protocol and the use of the (secure) signature-creation device in the smartphone. Note that the DSS server cannot access the (secure) signature-creation device without additional mechanisms; proposals to solve this are presented in section Section 1.7.3, “Proposed Solutions”.

Figure 6. A smartphone as a DSS client

This use case is a generalisation of use case 2. It assumes the use of a mobile device that may contain a (secure) signature-creation device, in the proximity of the end user. If the mobile device does not contain a (secure) signature-creation device it is assumed that it is located at the "SCD Service". The mobile device can have more capabilities than a mobile phone. For instance, a smartphone with an internet connection and an app to interact with the "SCD Service".

Figure 7. Signature creation delegated to another service

To sign (a) document(s), the client sends the document(s) to the DSS server. The DSS server delegates the actual computation of the digital signature value to another service: the digest is sent to the "SCD Service", with possibly (but not necessarily) a <dss:SignRequest> (A). The "SCD Service" is able to deliver a digital signature value, based on the interaction with the mobile device by means of a certain protocol.

If the smartphone contains a (secure) signature-creation device, it receives or retrieves the digest from the "SCD Service" and computes the digital signature value for the digest (3), after which the digital signature value is returned to the "SCD Service". The "SCD Service" responds with possibly (but not necessarily) a <dss:SignResponse> (B) to the DSS server.

Note that some secure correlation is required between the initial user request and the interaction with the smartphone.

This use case can make use of the ETSI standard for Mobile Commerce (M-COMM) or Mobile Signature Service [M-COMM]

To provide the Digital Signature Service access to a LSCD, a User Agent is introduced. The User Agent MUST provide access to the LSCD. The DSS client communicates with the DSS server via the User Agent; there is no direct communication between the DSS client and DSS server. The figure below illustrates how this is done.

Figure 8. A LSCD used by the DSS server

The order of actions is as follows:

For achieving this User Agent approach a transport binding needs to be introduced:

The OASIS DSS protocol could be split into two related request/response pairs, such that the client can obtain a digest of the document in the FIRST request/response. The client MUST be capable of accessing the LSCD. The client interacts with the LSCD to compute the digital signature value and sends it back to the DSS server by means of the SECOND request/response.

Figure 9. An LSCD used by the DSS client.

The order of actions is as follows:

Note that no assumptions are made about the actual connection or communication between the client and LSCD. (Although the core DSS protocol could be used to send a <dss:DocumentHash> to the LSCD and to obtain a <SignatureObject>.) The only assumption is that the client that implements the (client-side of the) DSS protocol is capable of using the LSCD.

For achieving this two-step approach some OptionalInputs and OptionalOutputs elements need to be introduced for the SignRequest or SignResponse:

The Digital Signature Service delegates the computation of the digital signature value to a third-party for users with a mobile device that MAY contain a (secure) signature creation device (in that case, the mobile device contains the LSCD). If the mobile device does not contain a (secure) signature-creation device it is assumed that the third-party provides access to the RSCD on behalf of the end user by means of the mobile device. See for instance Section 1.7.2.2, “Use Case 2” and Section 1.7.2.4, “Use Case 4” .

Figure 10. Signature creation delegated to a third-party.

Because the end user must be assured that it signs the correct request, an additional mechanism is introduced: a challenge code. The challenge code is a kind of 'one-time-password': it is different for every session. The challenge code will be shown at the client screen as well as the screen of the mobile device (the DSS server sends the challenge code to the third-party). The end user compares the codes and if they are the same confirms the sign request.

Note. The challenge code could even be used for a kind of challenge-response authentication by the Digital Signature Service. If the SignRequest also contains a response code, it is expected that the end user enters that code at the mobile device. The electronic signature is only created and processed (by the Digital Signature Service) if the response codes match. Note that the challenge-response does not protect the end user from misuse of the signature by the third-party. (But the signature is bound to the document by means of a unique hash value, making it useless for other documents.)

The DSS client MUST be able to create the challenge (and optionally a response) code, unique for every session, and MUST display the code(s) onto the screen of the client.

The order of actions is as follows:

The protocol between the Digital Signature Service and third-party is not specified by this profile, but the DSS protocol can be used for this as well, see for instance Figure 3, “Delegation of the signature creation to the LSCD or RSCD”. (It is assumed that the challenge code is included in the request to the third-party.)

Note that information is required about the identity of the end user to enable the third-party to communicate with the appropriate mobile device. It is assumed that the element <dss:ClaimedIdentity> is sufficient for this purpose.

For achieving this third-party approach some OptionalInputs elements need to be introduced for the SignRequest:

This clause profiles the use of Optional Input elements.

http://docs.oasis-open.org/dss-x/ns/localsig/user-agent

In case the end user cancelled the signing operation, the Digital Signature Service returns a <dss:ResultMajor> with the value RequesterError and a <dss:ResultMinor> with the value:

urn:oasis:names:tc:dss-x:profiles:localsig:user-cancelled

In case the Digital Signature Service detects a problem with the client runtime environment, the service returns a <dss:ResultMajor> with the value RequesterError and a <dss:ResultMinor> with the value:

urn:oasis:names:tc:dss-x:profiles:localsig:client-runtime-error

This clause profiles Optional Input elements.

http://docs.oasis-open.org/dss-x/ns/localsig/two-step-approach

   <xs:element name="ReturnDocumentHash">
      <xs:complexType>
         <xs:sequence>
            <xs:element 
                 minOccurs="0" maxOccurs="1"
                 ref="ds:DigestMethod"/>
         </xs:sequence>
         <xs:attribute 
                 name="MaintainRequestState" 
                 use="optional" 
                 type="xs:boolean"/>
      </xs:complexType>
   </xs:element>

   <xs:element name="CorrelationID" type="xs:NCName"/>

In response to a successfull processing of a <dss:SignRequest> that specified the element <localsig:ReturnDocumentHash>, the <dss:ResultMajor> contains the value Success and the <dss:ResultMinor> the value:

urn:oasis:names:tc:dss-x:profiles:localsig:document-hash

In response to a successfull processing of a <dss:SignRequest> that specified the element <localsig:SignatureObject>, the <dss:ResultMajor> and <dss:ResultMinor> follow the [DSSCore] specification.

This profile defines the new optional output elements.

This clause profiles the (new) elements for the OptionalInputs.

http://docs.oasis-open.org/dss-x/ns/localsig/delegation

   <xs:element name="ChallengeCode" type="xs:NCName"/>

   <xs:element name="ResponseCode" type="xs:NCName"/>

If the signature creation is cancelled by the end user the <dss:ResultMajor> contains the value for ResponderError and the <dss:ResultMinor> the value:

urn:oasis:names:tc:dss-x:profiles:localsig:user-cancelled

If the third-party is not able to handle the signature creation the <dss:ResultMajor> contains the value for ResponderError and the <dss:ResultMinor> the value:

urn:oasis:names:tc:dss-x:profiles:localsig:delegation-failed

If the response code that is returned by the third-party does not correspond to the value that is provided in the request, the <dss:ResultMajor> contains the value for ResponderError and the <dss:ResultMinor> the value:

urn:oasis:names:tc:dss-x:profiles:localsig:incorrect-responsecode