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, for instance a Document Management System (DMS). The web application (for instance a DMS) has implemented the DSS protocol to allow its users to sign documents. To sign (a) document(s), the user selects a document from wihin the web application (for instance a DMS) and the web application sends the document(s) to the DSS server; the DSS server obtains (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 obtains 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 contains 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 will 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 is able to access 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 contains 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 has to 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 is able to create the challenge (and optionally a response) code, unique for every session, and will 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 MUST return 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="RequestDocumentHash">
      <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:RequestDocumentHash>, 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, Section 2.6.

This profile defines the Optional Output elements.

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

This clause profiles the Optional Inputs elements.

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

The conformance level states that the Digital Signature Service cannot maintain state information between subsequent requests in the Two-Step approach.

The request MUST contain the element <dss:ServicePolicy> with the value

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

If a request contains the element <localsig:RequestDocumentHash> and the attribute value of MaintainRequestState is either absent or has a value of "false", then compute the digest value of the given input document. In case of success, the response MUST contain the element <dss:DocumentHash> with the digest value.

If a request contains the element <dss:SignatureObject> (and optionally, the <dss:DocumentHash>), then the server MUST create the signed document by means of the given <dss:SignatureObject> and the given input document. In case of success, the response MUST contain the signed document.

The element <localsig:CorrelationID> is ignored in a request; the element <localsig:CorrelationID> MUST NOT be returned in a response.

The conformance level states that the client of the Digital Signature Service is capable of computing a digital signature value based on a given digest value of a document

The requests MUST contain the element <dss:ServicePolicy> with the value

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

The FIRST request MUST contain the document to be signed as well as the element <localsig:RequestDocumentHash> for which the attribute MaintainRequestState is either absent or has a value of "false".

The <dss:DocumentHash> is obtained from the FIRST response and MUST be used to compute the digital signatue value.

The SECOND request MUST contain the document to be signed, as provided in the FIRST request, as well as the <dss:SignatureObject> that contains the digital signatue value.

If the FIRST request contained the <dss:DocumentHash> element, the SECOND request MUST contain that element too with the same value.

The conformance level 'Stateful' states that the Digital Signature Service is able to maintain state information between two subsequent requests (in the Two-Step approach).

The element <dss:ServicePolicy> MUST be present with the value

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

The FIRST request MUST contain the element <localsig:RequestDocumentHash> and the attribute MaintainRequestState="true" in the OptionalInputs. In case of success, the FIRST response MUST contain a reference to the state, by means of the element <localsig:CorrelationID> and MUST contain the digest value of the input document by means of the element <dss:DocumentHash>.

The SECOND request MUST contain the <dss:SignatureObject> and MUST contain the element <localsig:CorrelationID> that refers to the state of a corresponding (FIRST) request. The Digital Signature Service MUST use the referred state to create the signed document. In case of success, the SECOND response MUST contain the electronic signature or signed document, based on the input document found in the FIRST request and the referred state.

The conformance level states that the client of the Digital Signature Service is capable of computing a digital signature value based on a given digest value of a document

The FIRST request MUST contain the element <localsig:RequestDocumentHash>; the attribute MaintainRequestState is either absent or has a value of "false".

The FIRST request MUST NOT contain the element <localsig:CorrelationID>

The <dss:DocumentHash> obtained from the FIRST response MUST be used to compute the digital signatue value.

The SECOND request MUST contain the <dss:SignatureObject> that contains the digital signatue value.

The SECOND request MUST contain the element <localsig:CorrelationID> with the value that is obtained from the FIRST response.

If the FIRST request contained the <dss:DocumentHash> element, the SECOND request MUST contain that element too with the same value.

The conformance profile states that the Digital Signature Service is capable of using a HTTP User Agent.

The element <dss:ServicePolicy> MUST be present with the value

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

The request follows the [DSSCore] specification, Section 3.1. The response contains the electronic signature or signed document according to the request, as defined by the [DSSCore] specification, Section 3.2.

The server MUST implement the protocol binding according to Section 4.1, “WEB FORM Transport Binding”.

The server MUST be able to receive the digital signature value that has been computed by the user agent. The server MUST use the received digital signature value to create the signed document.

The conformance profile states that the Digital Signature Service is capable of delegating the signature creation to a third-party.

The element <dss:ServicePolicy> MUST be present in both requests with the value

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

The element <localsig:ChallengeCode>, MUST be present

The server MUST create a new SignRequest and send it to the Third Party. The SignRequest MUST contain the element <localsig:ChallengeCode>. and MUST NOT contain the element <localsig:ResponseCode>.

If the request contains the element <ds:DigestMethod> it must instruct the Third Party to use the specified digest method.

The server MUST wait for the SignResponse of the Third Party. In case of success, the SignResponse MUST contain the element <dss:SignatureObject>.

In case of success, the response MUST contain the electronic signature or signed document as requested, as defined by the [DSSCore] specification, Section 3.2, based on the input document and the <dss:SignatureObject> from the SignResponse of the Third Party.

The conformance profile states the same capabilities a level 1 and the server is capable acting upon a response code.

The request MUST contain the element <localsig:ResponseCode>.

The SignResponse from the Third Party MUST contain an element <localsig:ResponseCode> with the value that has been entered by the user.

When the server receives the SignResponse from the Third Party, the SignResponse MUST contain the element <localsig:ResponseCode>. The electronic signature or signed document MUST ONLY be created if and only if the value of the element <localsig:ResponseCode>, obtained from the Third Party, is the same as the value of the element <localsig:ResponseCode>, obtained from the client.

The conformance profile states that the client is capable of creating a challenge code and presenting the challenge code to the user.

The client MUST create a random value, the challenge code, that can easily be read and entered by a person.

The client MUST present the challenge code to the user. Information MUST be displayed to the user about the use of the code: the user has to compare the presented code with the code that is received from the Third Party. If the codes do not match, the user must cancel the operation.

The request MUST contain the element <localsig:ChallengeCode> with the challenge code.

The client MUST be able to create a request and process a response, as defined by the [DSSCore] specification.

The conformance profile states the same capabilities a level 1 and the client is capable of creating a response code.

The client MUST create a random value, the response code, that can easily be read and entered by a person.

The client MUST present the response code to the user. Information MUST be displayed to the user about the use of the code: the user has to enter the code into the application of the Third Party.

The request MUST contain the element <localsig:ResponseCode> with the response code.