Web Services Reference SealSign SQS

ElevenPaths, radical and disruptive innovation in security solutions

SealSign SQS (Signature Queue Services)

Web Services Reference

[email protected]

elevenpaths.com

SealSign SQS (Signature Queue Services) Web Services Reference

V.3.2 – October 2016

2016 © Telefónica Digital España, S.L.U. All rights reserved. Page 2 of 25

Table of content

1 Introduction ................................................................................................................ 3

2 SealSign SQS's Web Service Interfaces ......................................................................... 5

2.1 Common classes ....................................................................................................................... 5

2.1.1 QueueReference ......................................................................................................................... 5

2.1.2 JobReference .............................................................................................................................. 5

2.1.3 JobReferenceEx .......................................................................................................................... 6

2.1.4 STUButtonDefinition .................................................................................................................. 7

2.1.5 STUConfiguration ....................................................................................................................... 8

2.1.6 SignatureClientBehaviour ........................................................................................................... 8

2.1.7 Job .............................................................................................................................................. 9

3 Biometric Signature Queue Service SOAP 1.1 .............................................................. 10

3.1 Methods .................................................................................................................................. 10

3.1.1 AddQueue................................................................................................................................. 10

3.1.2 RemoveQueue .......................................................................................................................... 10

3.1.3 GetQueueReferences ............................................................................................................... 11

3.1.4 AddJob ...................................................................................................................................... 11

3.1.5 SetProcessedJob ....................................................................................................................... 11

3.1.6 RemoveJob ............................................................................................................................... 12

3.1.7 ChangeJobOwner ..................................................................................................................... 12

3.1.8 GetPendingJobs ........................................................................................................................ 13

3.1.9 GetProcessedJobs ..................................................................................................................... 13

3.1.10 GetJob....................................................................................................................................... 14

4 Distributed Signature on Client Equipment ................................................................. 15

4.1 Architecture of the Distributed Signature .............................................................................. 15

5 SQL Distributed Signature Service .............................................................................. 17

5.1 ISignatureProvider Interface .................................................................................................. 17

5.2 Signature Provider Registration .............................................................................................. 18

5.3 DefaultSignatureProvider ....................................................................................................... 18

5.3.1 Configuring the DefaultSignatureProvider ............................................................................... 19

5.4 Methods .................................................................................................................................. 22

5.4.1 BeginBiometricSignatureProvider ............................................................................................ 22

5.4.2 EndBiometricSignatureProvider ............................................................................................... 23

6 Resources .................................................................................................................. 24




Introduction

SealSign SQS (Signature Queue Services) is a module for managing biometric signature job queues. Its purpose is to simply queue documents that will be biometrically signed.

Documents are added to signature queues either through development, invoking the SealSign SQS service methods, or by printing the documents with a virtual printer in a Microsoft Windows environment. If you are going to use the virtual printer, you should bear in mind that the document to be printed is rendered and converted to PDF format before its signature.

Once added to a queue, these documents will be waiting to be signed by a signature agent. This agent, known as SQS Client, allows the consultation of pending signature jobs assigned to the user, providing him with the necessary functionality for the signature of each document, using a capture device for handwritten signatures. Currently, there are agents for the Windows platform and for Android devices.

With the architecture of queues, SealSign SQS offers the possibility of both signing any document in the system (through the rendering and conversion to PDF by the virtual printer), and its delivery from a computer signing the document in a different computer or tablet.

The following diagram shows the different SealSign SQS modules and their interaction with the other modules of the SealSign platform.

Image 01: SealSign SQS modules.

The virtual print and signature queues solution consists of the following modules:

SQS module (Signature Queue Services): This is the web service that manages signature job queues. Services provided by this module are used by the virtual printer module as well as by




agents for Windows and Android. On the other hand, SQS uses SealSign BSS web services to perform the inclusion process of handwritten signature of documents.

Virtual Printer module: With this module you can create one or more virtual printers on the Windows platform. Through the virtual printer, you can queue signature jobs without having to modify the existing applications.

Client module: This is the client application that signs jobs queued in SQS. With it you can capture handwritten signatures using Wacom tablets in Windows environments or using Android tablets

SealSign SQS displays its functions through Web Services based on WCF (Windows Communication Framework) technology. These services can be accessed and the applications therein implemented through most of the technology on the market.

This document provides a description of these services, as well as the possibility of customizing the signature behaviour of each queue through a special type of add-in, known as Signature Provider.




SealSign SQS's Web Service Interfaces

Given the diversity of technology available on the market and with the objective of being accessible from the majority of corporate applications, SealSign DSS's web services are accessible through two interfaces:

Interface based on the SOAP 1.1 (BasicHttpBinding) specification. It shows a single Web Service:

o Job queues service (SignatureQueueServiceBasic.svc): It manages and signs queued documents.

Interface based on the SOAP 1.2 and WS-Addressing (WsHttpBinding) specification. It shows the following Web Services:

o Job queues service (SignatureQueueService.svc): It manages and signs queued documents.

The services will be accessible in the SealSignSQSService virtual directory. For example: http://localhost/sealsigndssservice/signatureservice.svc

According to the technology and the capability of the client application, it will be possible to use one or other of the interfaces.

2.1 Common classes

The following classes are used as parameters in the Web services regardless of the interface they publish. These classes are defined within the SealSignSQSTypes.dll type library.

2.1.1 QueueReference

The consultation methods of pending jobs, GetPendingJobs, or processed jobs, GetProcessedJobs, receive an array of elements of this class with which the queue(s) you wish to consult are specified. You can get a list of existing queues by calling the GetQueueReferences method.

The QueueReferences class is defined as follows:

public class QueueReferences

{

public int id;

public string name;

}

Members:

id: ID of the job queue.

name: Name of the job queue.

2.1.2 JobReference

Each instance of this class represents each of the existing jobs in a queue. The consultation methods of pending jobs, GetPendingJobs, or processed jobs, GetProcessedJobs, will return an array of instances of this class.

http://localhost/sealsigndssservice/signatureservice.svc




The JobReference class is defined as follows:

public class JobReference

{

public int id;

public string idQueue;

public string owner;

public string computerName;

public int originalJobId;

public string jobTitle;

public DateTime time;

public byte[] blob;

public string JobMetadata;

}

Members:

id: ID of the job.

idQueue: It identifies the queue in which the signature job is stored.

owner: Account of the user listed as the job owner (in SAM format: domain\user). A job can only be consulted/signed/managed by its owner or by members of the SQS Administrators group (SealSignSQS Admins).

computerName: Name of the computer from which the job is added to the queue.

originalJobId: ID of the job in the print queue of the virtual printer. This identifier only makes sense if the job is added to the queue by printing the document through the virtual printer.

jobTitle: Title of the signature job.

time: Date and time of the last modification of the job. It contains the creation date and time of the job, or the date and time of the last signature.

blob: Array of bytes of the document to be processed at the current job.

JobMetadata: Character string associated with the document to be transferred to the signature provider. This is a free value that only makes sense between the two ends, that is, the process adding the job to the queue specifies a value that will be interpreted by the signature provider developed for this purpose. It is, therefore, a method for transparently transferring values between an SQS client and a customized signature provider.

2.1.3 JobReferenceEx

Each instance of this class represents each of the existing jobs in a queue. This class is returned by the job getting method known as GetJob.

The JobReferenceEx class is defined as follows:

public class JobReferenceEx

{

public int id;

public string idQueue;

public string owner;

public string computerName;




public int originalJobId;

public string jobTitle;

public DateTime time;

public byte[] blob;

public bool processed;

public string JobMetadata;

}

Members:

id: ID of the job.

idQueue: It identifies the queue in which the signature job is stored.

owner: Account of the user listed as the job owner (in SAM format: domain\user). A job can only be consulted/signed/managed by its owner or by members of the SQS Administrators group (SealSignSQS Admins).

computerName: Name of the computer from which the job is added to the queue.

originalJobId: ID of the job in the print queue of the virtual printer. This identifier only makes sense if the job is added to the queue by printing the document through the virtual printer.


time: Date and time of the last modification of the job. It contains the creation date and time of the job, or the date and time of the last signature.

blob: Array of bytes of the document to be processed at the current job.

processed: Boolean indicating whether the document has already been signed (true) or its signature is still pending (false).

JobMetadata: Character string associated with the document to be transferred to the signature provider. This is a free value that only makes sense between the two ends, that is, the process adding the job to the queue specifies a value that will be interpreted by the signature provider developed for this purpose. It is, therefore, a method for transparently transferring values between an SQS client and a customized signature provider.

2.1.4 STUButtonDefinition

Class for the definition of the area to be taken as a button on a Wacom STU tablet. These values only make sense if the SQS client to be used is the Windows client, and the tablet to perform the signature is one of the Wacom STU tablets supported by SealSign.

The STUButtonDefinition class is defined as follows:

public class STUButtonDefinition

{

public int x1;

public int y1;

public int x2;

public int y2;

}




Members:

x1: X coordinate in pixels of the upper left corner of the button. Its value can vary depending on the resolution of the tablet used.

y1: Y coordinate in pixels of the upper left corner of the button. Its value can vary depending on the resolution of the tablet used.

x2: X coordinate in pixels of the lower right corner of the button. Its value can vary depending on the resolution of the tablet used.

y2: Y coordinate in pixels of the lower right corner of the button. Its value can vary depending on the resolution of the tablet used.

2.1.5 STUConfiguration

Class for the definition of the signature behaviour in a Wacom STU tablet. These values only make sense if the SQS client to be used is the Windows client, and the tablet to perform the signature is one of the Wacom STU tablets supported by SealSign.

The STUConfiguration class is defined as follows:

public class STUConfiguration

{

public byte[] image;

public STUButtonDefinition OKButton;

public STUButtonDefinition CancelButton;

}

Members:

image: Array of bytes of the image that will be displayed on the screen of the Wacom STU tablet.

OKButton: Definition of the tablet area that will be treated as the OK button.

CancelButton: Definition of the tablet area that will be treated as the Cancel button.

2.1.6 SignatureClientBehaviour

Class for the definition of the SQS client process behaviour during the signature of the document. Objects of this class will be returned by the customized document providers to indicate the SQS client its behaviour in a document signature process.

The SignatureClientBehaviour class is defined as follows:

public class SignatureClientBehaviour

{

public string uri;

public string signatureId;

public string signatureAccount;

public string providerParameter;

public string signatureWindowTitle;

public STUConfiguration stuConfiguration;

}




Members:

uri: URI ID of the document to be processed. This field works as an internal identifier between the client and the signature provider.

signatureId: Field added to the biometric signature. The value of this field is specified by the caller application.

signatureAccount: Field added to the biometric signature. The value of this field is specified by the caller application.

providerParameter: Text string that transfers information between the client and the signature provider to customize its behaviour.

signatureWindowTitle: Title of the signature window that will be displayed on the client SQS.

stuConfiguration: Configuration of the Wacom STU tablet for the signature process of the current job.

2.1.7 Job

It defines both the job to be processed and the required SQS client behavior in order to perform the signature of the associated document.

The Job class is defined as follows:

public class Job

{

public SignatureClientBehaviour[] signatureClientBehaviour;

public JobReferenceEx jobReferenceEx;

}

Members:

signatureClientBehaviour: Array of signature behaviours. An object is returned for each of the signatures that must be included in the document.

jobReferenceEx: Signature job information.




Biometric Signature Queue Service SOAP 1.1

The ISignatureQueueServiceBasic.svc of SealSign SQS service shows the methods required to manage queues and biometric signature jobs with a SOAP 1.1 web service (basicHttpBinding).

The queue service shows various methods to manage jobs and signature queues.

The interface of this method, and classes and types related to it, are described in the following sections.

3.1 Methods

3.1.1 AddQueue

Description It creates a new biometric signature queue.

Syntax public int AddQueue (

string name

);

Input parameters

name: Name that will be given to the queue.

Return It returns an integer with the internal identifier associated with the queue.

Comments Only members of the SQS Administrators group (SealSignSQS Admins) can invoke this method.

3.1.2 RemoveQueue

Description It deletes an existing biometric signature queue.

Syntax public void RemoveQueue (

int id

);

Input parameters

id: Internal identifier of the queue you wish to delete.

Comments Only members of the SQS Administrators group (SealSignSQS Admins) can invoke this method.




3.1.3 GetQueueReferences

Description It returns the list of existing queues on the SQS server.

Syntax public QueueReference[] GetQueueReferences();

Return It returns an array of objects of QueueReference class, each of them with information on an existing job queue in the server.

3.1.4 AddJob

Description It adds a job to a biometric signature queue.

Syntax

public int AddJob (

string queueName,

int originalJobId,

string jobTitle,

byte[] blob,

string jobMetadata

);

Input parameters

queueName: Name of the queue to which the job is added.

originalJobId: ID of the print job.


blob: Array of bytes of the document to be signed.

jobMetadata: Metadata associated with the document.

Return It returns an integer with the identifier associated with the new signature job.

Comments

This method adds a new job to the queue and leaves its signature pending by providing the queue name and the array of bytes of the document to be signed.

You can add information associated with the document in the jobMetadata field. The value of this field will arrive, both to the signature provider and to the client process that subsequently carries out the document signature, just as it was saved in the queue. It is therefore a method to transfer information between the different modules involved in the queuing system.

3.1.5 SetProcessedJob

Description It changes the status of a job from signature pending to processed.

Syntax

public void SetProcessedJob (

int id, byte[] document

);




Input parameters

id: ID of the signature job.

document: Array of bytes of the signed document.

Comments

Jobs in a signature queue can have two statuses: signature pending or processed (signed).

Although the document status is automatically updated when the last of the signatures is performed, you can force the status change by invoking this method.

The document parameter is optional. If an array of bytes is transferred, this will be stored in the queue as a signed document. In the event that a null value is transferred, the existing document will stay a signed document.

Only the job owner or members of the SQS administrators group can invoke this method.

3.1.6 RemoveJob

Description It removes a job from a queue.

Syntax public void RemoveJob (

int id );

Input parameters


Comments Only the job owner or members of the SQS administrators group can invoke this method.

3.1.7 ChangeJobOwner

Description It changes the account of the user that owns the job.

Syntax

public void ChangeJobOwner (

int id, string newOwner

);

Input parameters


newOwner: User account of the new owner.

Comments

Only the job owner or members of the SQS administrators group can invoke this method.

The account of the new owner is set in SAMAccountName format (Domain\User).




3.1.8 GetPendingJobs

Description It gets the pending jobs list for one or more job queues.

Syntax

public JobReference[] GetPendingJobs (

QueueReference[] queueReferences,

string owner, string computerName

);

Input parameters

queueReferences: Array of queues to be consulted.

owner: Account of the job owner.

computerName: Computer for the consultation.

Return It returns a JobReference array with the list of pending jobs.

Comments

You can consult one or more queues at the same time by specifying an array of one or more objects of QueueReference class. If a null value is specified in the queueReferences parameter, all existing queues in the server will be consulted.

If the user invoking this method is an administrator user, he will be able to filter by owner or by computer, specifying the account value in the owner or computerName parameters.

If the user does not have administrator privileges, only the jobs he owns will be returned.

3.1.9 GetProcessedJobs

Description It gets the list of processed jobs for one or more job queues.

Syntax

public JobReference[] GetProcessedJobs (

QueueReference[] queueReferences,

string owner, string computerName

);

Input parameters

queueReferences: Array of queues to be consulted.

owner: Account of the job owner.

computerName: Computer for the consultation.

Return It returns a JobReference array with the list of pending jobs.

Comments

You can consult one or more queues at the same time by specifying an array of one or more objects of QueueReference class. If a null value is specified in the queueReferences parameter, all existing queues in the server will be consulted.




If the user invoking this method is an administrator user, he will be able to filter by owner or by computer, specifying the account value in the owner or computerName parameters.

If the user does not have administrator privileges, only the jobs he owns will be returned.

3.1.10 GetJob

Description It gets the information of a job existing in a signature queue.

Syntax public Job GetJob (

int id );

Input parameters


Return It returns an object of Job type with the signature job information.

Comments Only the job owner or members of the SQS administrators group can invoke this method.




Distributed Signature on Client Equipment

Given that the biometric signature requires the existence of a handwritten signature capture device, it could be considered that the whole process must take place using the client's equipment. This architecture based solely on client equipment has several problems such as the processing capacity and diversity of said equipment.

One of the advantages that SealSign BSS provides is the distributed signature, which allows the scenario in question to be resolved in a flexible, simple manner. The distributed signature consists of performing the whole signature process on the server side except for the capturing of the biometric signature parameters which is produced on the client side, where the capture device is located. The obtaining of external elements is thus unified and optimised and the amount of information exchanged is drastically reduced.

This process is carried out securely in SealSign BSS in order to ensure the safety of the data on two levels

Application level decoding the exchanged information.

Infrastructure level, allowing the use of underlying communications technology (SSL, authentication, etc.).

An additional advantage of this model is the simplicity of the client side which allows the simple integration of a multitude of different technologies, such as different operating systems (Windows, Linux, etc.) and different devices (PCs, mobiles, tablets, etc.).

4.1 Architecture of the Distributed Signature

SealSign SQS acts as a frontend service within the architecture of the SealSign BSS distributed signature. This architecture is primarily provided by three components:

Figure 02: SealSign SQS Architecture.

1. SealSign BSS backend service (BiometricSignatureServiceBasic.svc for SOAP 1.1 environments or BiometricSignatureService.svc): This service runs the signature process on the requested document.

Entidades Externas SealSign SQS/BSS Server Aplicación Cliente

Clientes Windows SealSignBSSPanel

Frontend (SQS) SignatureQueueSer

viceBasic

Backend (BSS) BiometricSignature

Service

SignatureProvider

MOSS SignatureProvider

Entidades Certificadoras

SAP

Clientes IOS SealSignBSSPanelView

Clientes Android SealSignBSSPanel




2. SealSign SQS frontend service (SignatureQueueServiceBasic.svc for SOAP 1.1 environments or SignatureQueueService.svc): This service orchestrates the communication between the client, job queue where the document is located, and the backend service. It can also modify the signature parameters as well as the tablet behaviour and the storage of the signed document in external repositories. This is achieved by developing and configuring an add-in type known as Signature providers.

3. Signature client component specific for each platform: It forms the biometric data of the handwritten signature that will be incorporated to the document being signed. In the SealSign BSS platform, versions of the component for .NET, Java, Android and iOS applications are included.

For more information on the architecture of the SealSign BSS distributed signature, see the SealSign BSS Web Services Reference Guide.

http://es.slideshare.net/elevenpaths/web-services-reference-sealsign-bss





SQL Distributed Signature Service This section describes the SQS queue front service, which orchestrates all components involved in the biometric signature process of queued jobs.

The SQS queue service can, in a way that is transparent to clients, integrate the biometric signature of documents located in job queues, as well as store them in external repositories. Access to repositories, signature parameters and the definition of the behavior of the capture device are solved with a system of installable components or plug-ins that can be easily incorporated to the service.

These signature providers can be developed by Eleven Paths as well as by any other company to facilitate the integration of repositories. Components should be developed in .NET and must meet the ISignatureProvider interface.

5.1 ISignatureProvider Interface The access interface of signature parameters definition has three methods that solve the definition of the behaviour of the capture process, the obtaining of biometric signature parameters and the potential storage of the signed document in an external repository:

using SealSignDSSTypes;

using SealSignBSSTypes;

using SealSignSQSTypes;

namespace SealSignSQSService

{

interface ISignatureProvider

{

SignatureClientBehaviour[] GetClientBehaviour(

int originalJobId,

string jobTitle,

string jobMetadata,

byte[] document);

void GetSignatureParameters(

int signatureIndex,

string uri,

string providerParameter,

int originalJobId,

string jobTitle,

string jobMetadata,

byte[] document,

out SignatureProfile signatureProfile,

out BiometricSignatureType biometricSignatureType,

out BiometricSignatureFlags biometricOptions,

out BiometricSignatureParameters biometricParameters,

out SignatureFlags options,

out SignatureParameters parameters,

out byte[] detachedSignature);

void SetSignedDocument(int signatureIndex,

string uri,


int originalJobId,

string jobTitle,

string jobMetadata,

byte[] signedDocument);

}

}




When the SealSign SQS client invokes a GetJob, the service invokes the GetClientBehaviour method of the signature provider. This method returns a SignatureClientBehaviour array with one element for each of the signatures that must be requested, as well as the behaviour of the tablet used for the capture (title of the capture window, background image, etc...).

At the beginning of each signature, SealSign SQS calls the GetSignatureParameters method of the signature provider so that it returns the biometric signature parameters (signature type, position of the chart, etc...) corresponding to the signature whose number is indicated in the signatureIndex parameter. The uri and providerParameter parameters will be used to transfer information from the signature client to the customized signature provider. Under no circumstances will they be used by the queue service itself. The uri parameter can be used as an internal identifier of the document (for example, to identify the document within a repository). The providerParameter parameter can be used to transfer complex information (for example, using an XML) from the SQS client to the signature provider.

At the end of each signature, SealSign SQS calls the SetSignedDocument method of the signature provider with the signed document. At this point, the signature provider can store the signed document in an external repository.

5.2 Signature Provider Registration

Signature providers are registered at job queue level, that is, you can register a different signature provider for each queue, thus defining a different signature process behaviour depending on the processed queue.

To register a customized signature provider in the system, just add a key with the protocol identifier and the declaration of the assembly that implements it in the <SignatureProviders> section of the SQS SignatureProviders.config file. This assembly can be located both in the default search path and the in the GAC (Global Assembly Cache). For example:

<add key="queue1" value="SampleSignatureProvider, Version=1.0.0.0, Culture=neutral,

PublicKeyToken=7292d37ec3154539"" />

5.3 DefaultSignatureProvider

During the installation of SealSign SQS, a default signature provider is also installed, which will be applied to all of those queues that do not have a configured signature provider.

This default signature provider configures one or more biometric signature profiles. Each of these profiles includes:

A filter: Text that, when found within the document, forces the signature profile application for such document.

An array of capture process definition: For each requested signature, values such as window title, background image of the tablet, etc., will be defined.

Biometric signature parameters: Signature type, position, chart size...




5.3.1 Configuring the DefaultSignatureProvider

All default configurations of the signature provider are established by editing the DefaultSignatureProvider.dll.xml file located in the bin folder, under the installation folder of the SQS service.

The following are the initial contents of this file:

<?xml version="1.0"?>

<DefaultProviderConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<signatureProfiles>

<Profile>

<profileName>Default Profile</profileName>

<signatureConfiguration>

<SignatureConfiguration>

<signatureClientBehaviour>

<signatureId />

<signatureAccount />

<providerParameter />

<signatureWindowTitle>Firme Aquí . . .</signatureWindowTitle>

</signatureClientBehaviour>

<signatureProfile>PDF</signatureProfile>

<biometricSignatureType>Default</biometricSignatureType>

<biometricOptions>Default</biometricOptions>

<options>Default</options>

</SignatureConfiguration>

</signatureConfiguration>

</Profile>

</signatureProfiles>

</DefaultProviderConfiguration>

You can add as many <Profile> nodes as there are signature/document types to be signed. Within each of them, in addition to the profile name, you can add a <filterText> node with text that will work as a filter for the application of this profile to the document. If the configured text is located within the document, the signature configurations established within the <signatureConfiguration> node will be applied to it.

A number of <SignatureConfiguration> nodes will be added to the <signatureConfiguration> node of a profile, as many as there are signatures required by a type of document.

Within this node, you can configure the following elements, which will match the serialization in XML format with their corresponding class:

ELEMENT CLASS

<signatureClientBehaviour> SignatureClientBehaviour

<signatureProfile> SignatureProfile

<biometricSignatureType> BiometricSignatureType

<biometricOptions> BiometricSignatureFlags

<biometricParameters> BiometricSignatureParameters

<options> SignatureFlags

<parameters> SignatureParameters.




Finally, at the same level as the <signatureProfiles>, you can create an <otherParameters> node with the following structure:

<otherParameters>

<STUDefaultConfig>

<ImagePath>C:\wacom\imagen_de_fondo.bmp</ImagePath>

<OKButton>

<x1>491</x1>

<y1>20</y1>

<x2>620</x2>

<y2>70</y2>

</OKButton>

<CancelButton>

<x1>21</x1>

<y1>20</y1>

<x2>148</x2>

<y2>70</y2>

</CancelButton>

</STUDefaultConfig>

</otherParameters>

With this node, you can configure the default values returned by the GetClientBehaviour method regarding the definition of the background image and the area of the OK and Cancel buttons for Wacom STU tablets.

The following is an example of a complete configuration file:

<?xml version="1.0"?>

<DefaultProviderConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<signatureProfiles>

<Profile>

<profileName>Default Profile</profileName>

<signatureConfiguration>



<signatureId />



<signatureWindowTitle> Sign here. . . .</signatureWindowTitle> </signatureClientBehaviour>







</Profile>

<Profile>

<profileName>Profile 1</profileName>

<filterText> Work contract </filterText> <signatureConfiguration>



<signatureId />



<signatureWindowTitle> Signature of the Worker. . . .</signatureWindowTitle>








<biometricParameters>

<imageParameters>

<attachmentName />

<imageTokenText />

<autoSize>false</autoSize>

<height>55</height>

<width>90</width>

<offsetX>120</offsetX>

<offsetY>40</offsetY>

<signatureVisible>true</signatureVisible>

<onPage>1</onPage>

<onAllPages>false</onAllPages>

<onLastPage>true</onLastPage>

<pageOffset>0</pageOffset>

<rotate>0</rotate>

</imageParameters>

</biometricParameters>





<signatureId />



<signatureWindowTitle> Signature of the Company. . . .</signatureWindowTitle>





<biometricParameters>

<imageParameters>

<attachmentName />

<imageTokenText />

<autoSize>false</autoSize>

<height>55</height>

<width>90</width>

<offsetX>220</offsetX>

<offsetY>40</offsetY>

<signatureVisible>true</signatureVisible>

<onPage>1</onPage>

<onAllPages>false</onAllPages>

<onLastPage>true</onLastPage>

<pageOffset>0</pageOffset>

<rotate>0</rotate>

</imageParameters>

</biometricParameters>




</Profile>

</signatureProfiles>

<otherParameters>

<STUDefaultConfig>

<ImagePath>C:\inetpub\wwwroot\SealSignSQSService\bin\wacom.bmp</ImagePath>

<OKButton>

<x1>491</x1>

<y1>20</y1>

<x2>620</x2>

<y2>70</y2>

</OKButton>

<CancelButton>

<x1>21</x1>




<y1>20</y1>

<x2>148</x2>

<y2>70</y2>

</CancelButton>

</STUDefaultConfig>

</otherParameters>

</DefaultProviderConfiguration>

5.4 Methods

5.4.1 BeginBiometricSignatureProvider

Description It starts a distributed signature process using the SealSign SQS service.

Syntax

BiometricSignatureContext BeginBiometricSignatureProvider(

int idDocument,

int signatureIndex,

string queueName,

string biometricId,

string biometricAccount,

string uri,


byte[] document);

Input parameters

idDocument: ID of the document in the job queue.

signatureIndex: Index of the signature to be included.

queueName: Name of the job queue in which the document is stored.

biometricId: Field added to the biometric signature. The value of this field is specified by the caller application.

biometricAccount: Field added to the biometric signature. The value of this field is specified by the caller application.

uri: URI ID of the document. For more information on this value, see the description of the ISignatureProvider interface.

providerParameter: Text string that transfers information between the client and the signature provider to customize their behaviour. For more information on this value, see the description of ISignatureProvider interface.

document: Array of bytes with the content of the document to be signed. If a null value is transferred, the document is obtained from the job queue through the idDocument field.

Return

It returns an object of BiometricSignatureContext class with the ID of the signature transaction and an array of bytes with the distributed signature context to be processed on client. For more information on this class, see the SealSign BSS Web Services Reference Guide.

Comments There are two ways of locating the document to be signed: transferring a document identifier in the idDocument parameter or providing the array of bytes of the document in the document parameter. If the document field contains a






value, the idDocument parameter is ignored. Otherwise, the idDocument value is used to locate the document in the job queue.

It may be necessary to add more than one signature to a document to be signed. In the signatureIndex field, the order number of the signature to be included in the document is specified, starting from zero.

5.4.2 EndBiometricSignatureProvider

Description It completes a distributed signature process that has been initiated by the BeginBiometricSignatureProvider method.

Syntax

void EndBiometricSignatureProvider(Guid instance,

byte[] biometricState, int idDocument,

int signatureIndex,

string queueName,

string uri,


out byte[] signedDocument);

Input parameters

instance: Transaction identifier for the signature returned by the beginBiometricSignatureProvider method.

biometricState: Byte array for the distributed signature status after this has been processed by the AsyncStateManager component.

idDocument: ID of the document in the job queue.

signatureIndex: Index of the signature to be included.

queueName: Name of the job queue in which the document is stored.

uri: URI ID of the document. For more information on this value, see the description of the ISignatureProvider interface.

providerParameter: Text string that transfers information between the client and the signature provider to customize their behaviour. For more information on this value, see the description of ISignatureProvider interface.

Output Parameters

signedDocument: Array of bytes with the contents of the document once it has been signed.




Resources

For information about the different SealSign services available, please go to this address:

https://www.elevenpaths.com/technology/sealsign/index.html

Also, on the ElevenPaths blog you can find interesting articles and innovations regarding this product.

You can find more information about Eleven Paths products on YouTube, on Vimeo and on Slideshare.

http://blog.elevenpaths.com/

https://www.youtube.com/user/ElevenPaths

http://vimeo.com/elevenpaths

http://www.slideshare.net/elevenpaths/




PUBLICATION

October 2016

At ElevenPaths we have our own way of thinking when we talk about security. Led by Chema Alonso, we are a team of experts who are passionate about their work, who are eager to redefine the industry and have great experience and knowledge about the security sector.

Security threats in technology evolve at an increasingly quicker and relentless pace. Thus, since June 2013, we have become a startup company within Telefónica aimed at working in an agile and dynamic way, transforming the concept of security and, consequently, staying a step ahead of our attackers.

Our head office is in Spain, but we can also be found in the UK, the USA, Brazil, Argentina and Colombia.

IF YOU WISH TO KNOW MORE ABOUT US, PLEASE CONTACT US AT:

elevenpaths.com Blog.elevenpaths.com @ElevenPaths Facebook.com/ElevenPaths YouTube.com/ElevenPaths

The information disclosed in this document is the property of Telefónica Digital España, S.L.U. (“TDE”) and/or any other entity within Telefónica Group and/or its licensors. TDE and/or any Telefonica Group entity or TDE’S licensors reserve all patent, copyright and other proprietary rights to this document, including all design, manufacturing, reproduction, use and sales rights thereto, except to the extent said rights are expressly granted to others. The information in this document is subject to change at any time, without notice.

Neither the whole nor any part of the information contained herein may be copied, distributed, adapted or reproduced in any material form except with the prior written consent of TDE.

This document is intended only to assist the reader in the use of the product or service described in the document. In consideration of receipt of this document, the recipient agrees to use such information for its own use and not for other use.

TDE shall not be liable for any loss or damage arising out from the use of the any information in this document or any error or omission in such information or any incorrect use of the product or service. The use of the product or service described in this document are regulated in accordance with the terms and conditions accepted by the reader.

TDE and its trademarks (or any other trademarks owned by Telefonica Group) are registered service marks.

Technology

Web Services Reference SealSign SQS