Documento Nacional de Identidad electrónico is the Spanish eID. It is in line with the EU directive on electronic ID, and it is a "smart" identity card with a chip containing certificates for authentication and digital signature, similar to Estonian ID-kaart, Belgian .beid and many others. The cards are issued to Spanish citizens and can of course be used for regular "real world" authentication, but in order to use it electronically the subject must physically go to a passport issuing police station where he/she can activate the chip on the card using a self service kiosk, "Punto de actualicaćion del DNIe" ("activation point for the DNIe", see image).
The end user portal for information on DNIe is located at http://usatudni.es/dnie/ ("Usa tu DNIe" means "Use your DNIe"). The site contains information regarding what DNIe is, how to use it and where you can use it. There is no central support organization where you can ask for help with your DNIe. When assisting end users with their DNIe problems, please refer to http://zonatic.usatudni.es/aplicaciones/asistente-dnie.html which provides software downloads and also a client executable which can be downloaded and used to verify the certificates of a DNIe card.
A live demo speaks a million words. You may see a live demo of DNIe authentication and signature at http://demo.signicat.com/dnie.
DNIe authentication is implemented using bilateral SSL, meaning that the user requests a protected resource with Signicat which can only be accessed if a DNIe client certificate is attached to the request. This will trigger built-in browser functionality to search the computer for a smartcard/certificate, and the user enters a PIN or password to unlock the certificate. DNIe authentication requires that smartcard drivers for the reader and DNIe card are present on the computer.
The flow through the signature module is visualized in the following figure:
Signed document format
The result of the signing process is an XMLDSig:
You may ask firstname.lastname@example.org to set up a "Health" module for you. You may use the health module to inspect the state of the service at any time, or you may choose to set up automatic monitoring. For the user interface, please visit http://demo.signicat.com and choose the "Health" option. If you remove the format=html parameter then you will receive a JSON representation of the same data, suitable for consumption by your own monitoring service.
The entry point for technical information regarding DNIe is http://www.dnielectronico.es. The material is available in Spanish only. This is also where the certificates belonging to the DNIe certificate hierarchy are downloaded, and where specifications etc. are found. (See also the complete certificate policy.)
The following illustrates the certificate hierarchy for DNIe:
AC stands for Autoridad de Certificación which obviously means Certificate Authority. "Raiz" is Spanish for "root".
The figure illustrates that AC RAIZ has issued three intermediate CA certificates numbered accordingly. All of the intermediate certificates are used to issue client certificates to subjects. In addition, the 001 intermediate certificate is the issuer of the OCSP responder certificate. The OCSP certificate is issued to FNMT (Fábrica Nacional de Moneda y Timbre, "National producer of money and stamps").
Please note that there is no test infrastructure for DNIe. There are no test certificates, no test OCSP responders and no PKI infrastructure for testing at all. Still, Signicat may have DNIe set up for you in the test environment at preprod.signicat.com, but it will have to be configured to use production certificates. Obviously, this means that production DNIe certificates must be used for testing the service.
If you don't have access to production DNIe certificates, then the service may be set up to use smartcards belonging to another CA infrastructure (such as the Estonian) that provide test cards. Please contact email@example.com for more information regarding the possibilities for custom test infrastructures.
You may refer to How to work with graphical profiles to get a basic understanding of graphical profiles in the Signicat pipeline. The following is the minimum required for a graphical profile that is to be used with DNIe:
Minimal graphical profile
If you would like to customize your graphical profile, then there are a few special considerations to note when it comes to DNIe:
This is the HTML graphical profile which was used to create that look:
Profile suitable for authentication
You may not wrap the PDF document viewer itself in your graphical profile. If you wish to achieve such an effect, you need to run the Signicat process in an iframe. Please see Using IFrames for more information on that. If you would like, you may add custom graphics to the dialog box which contains the signature process, illustrated in the following figure:
To include your own branding or graphics in the graphical profile for DNIe signature, you may request to have the dialog box size set to any size you would like, and you may then add customizations to the graphical profile for DNIe signatures. In the figure above, the iframe has been extended to be 542x432 pixels, and the following HTML is used for the content in the dialog box:
Profile suitable for signatures
Graphical profiles will need to be maintained and tested by yourself. You may request changes and asset uploads and deployment at any time by contacting firstname.lastname@example.org.
Testing your production certificates
When you have your own configuration on Id.Signicat, you may test your merchant certificate for production. The test must be carried out by authenticating real users, or signing documents on your configuration for production.
Upon entering the method, the end user will see the following screen:
The heading translates to "Please insert your DNIe in the card reader". The links say "Help" and "Cancel", and the green button says "Continue". The end user clicks the continue button, upon which an attempt is made to try and load the protected resource from Signicat servers. This will trigger built-in functionality in the browser to prompt the user for a certificate and a PIN-code, during which time the following screen is shown in the background:
"Please wait, establishing communication with your DNIe."
If the process is unsuccessful for any reason, then the user is presented with a final screen:
"Authentication error. You need to restart your browser if you would like to try again. Sorry about the inconvenience." (This is one of the downsides of 2-way SSL...) When the user now hits the continue button (or the cancel link), the end user is sent to target with the following SAML response:
If the process is successful and the certificate is determined to be valid, the end user obviously won't see the "authentication failed"-screen, but will instead be sent to target along with the SAML response.
When the signature process is started, the user is presented with information on how to proceed. The PDF-document is visible in the background throughout the whole signature process:
Clicking continue brings the PDF-document to the foreground:
The user can read, zoom in/out and download the document before continuing the signature process. Clicking the sign button brings up a view instructing the user to insert the DNIe card into the card reader:
Detection of Java starts when the user clicks the continue button. The user is free to click the cancel link to bring the PDF-document to the foreground again.
If Java cannot be found the user is presented with a link to download the latest version:
If the Java version is too low (compared to what's configured by us), the user is notified:
If Java is found and the version is found to be OK, the applet is loaded. The applet will not be visible to the end user, but is needed for communication with the smart card.
After loading the applet, the applet will try to communicate with the smart card to get hold of the certificates:
If the user did not install the drivers needed for Linux/OS X (see separate section), the signature process will fail.
If the drivers are found, but not reachable by the applet due to browser sandboxing, the following view is displayed:
This is a known issue in Safari on OS X, which by default prevents plugins (in this case applets) from gaining access to system resources, such as files.
If the drivers are found, but the card cannot be found, the user is notified and given a chance to try again (e.g. if the card was not inserted correctly the first time):
If the card can be read, a view with all non-repudiation certificates is displayed. By default no certificate is selected:
The user has to actively select one to be able to continue. Selecting a certificate from the drop-down menu brings up the following information about the certificate: subject, issuer,validity period, key usage and serial number:
A test card from ESTEID was used in the example above. Unfortunately there's no such thing as DNIe test cards.
Selecting a certificate and clicking the continue button brings up the confirmation view. This view comes in two variations, based on the operating system of the user.
Users running Linux/OS X are asked to provide the password/PIN before continuing:
By clicking the sign button, the user confirm that he/she has read and understood the document.
If the password/PIN is incorrect, the user is notified:
Users running Windows will not need to input the password/PIN prior to clicking the sign button:
This is because Windows takes care of the password/PIN input. The PIN popup is displayed after the user clicks the sign button:
This popup also takes care of notifying the user if the password/PIN was incorrect:
If everything goes well, the document gets signed and sent to the server. The user is then presented with a final view with the option to complete the signature process by pressing the continue button:
If something goes wrong during any of the steps in the signature process, the error is reported back to the server (if it was client-side) and a generic failure view is displayed:
Upon clicking the continue button, the process will be aborted.
Authentication using SAML 1.1
Commonly, the authentication process starts in your application and will consist of the following steps. You are required to carry out the actions marked in bold.
- Redirecting the user to Signicat: You are the service provider (SP) and you need to authenticate an end user in order to grant him or her access to some service. In order to do that, you redirect the user to Signicat (in the browser).
- Signicat will host the entire authentication process using any of the available (or desired) id methods, after which a SAML assertion (XML) is constructed. The SAML assertion will be signed with a certificate which ensures that the contents of the assertion cannot be spoofed or altered.
- Receiving the SAML response: Signicat will then redirect the user back to your application along with the aforementioned SAML assertion.
- Verifying the SAML response: Your application will pick up the SAML assertion and validate it to make sure it's correct.
- Retrieving attributes from the SAML response: After validation has taken place, the values in the SAML assertion (such as user name, personal identity number etc.) can be extracted and processed by your application for further usage (typically logging the user in).
Redirecting the user to Signicat
The first step of the authentication process is as easy as constructing a URL. The URL will have the following format:
the red parts will depend on what you want to do:
envis the environment. When you're first starting out, this will typically be
preprod, and in production it will be
serviceis the name of your service as registered with Signicat*. There is a demo preprod service called
demowhich you may use as you'd like, but eventually you will start using your own service.
methodis the name of the id-method as registered with Signicat*. Common abbreviations are
nbidfor Norwegian BankID,
sbidfor Swedish BankID,
nemidfor Danish NemID,
tupasfor Finnish Tupas,
esteidfor Estonian ID-card and so on.
profileis the name of the graphical profile** you would like to use. If you don't have a graphical profile, you can omit the value and the default profile will be used.
languageis the (ISO 639-1) two letter code for the language you would like in the user interface, such as
etfor Estonian and so on.
targetis the URL-encoded (or "percent encoded") URL to the application which is to receive the SAML assertion. If you're starting out testing the services, then perhaps your URL is
http://localhost:8080/auth/verifyand if you URL encode that you'll end up with
http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fverify. Any parameters you use in any of your URL's should always be URL encoded according to the URL standard, so make sure you adhere to that.
* If your company name is Foo then your service name can be "foo", and if you're using Danish NemID then the method name can be "nemid" or something completely different if you'd like. Please contact email@example.com if you're unsure of the name of your service and/or available id-methods.
** A graphical profile is an HTML template which can be used to wrap the dynamic content served by Signicat. See also How to work with graphical profiles.
Let's put the pieces together and construct a URL where we send the user to the preprod environment, using the demo service, the Danish NemID method, a demo profile, danish language and localhost as the target:
Clicking the link will send you to a page where the NemID applet is loaded and the authentication process starts, such as in the following screenshot:
Receiving the SAML response
After authenticating, Signicat will redirect the user to the target using HTTP POST. In terms of HTTP, this is what the request would like like:
SAML 1.1 POST profile
Decoding the SAML response will result in the actual SAML (XML) document which contains information about the authentication. Read more about SAML or have a look at example SAML responses for different id providers.
Verifying the SAML response
The SAML response is a signed XML (xml-dsig) and the signature must be verified in order to ensure the correctness of the assertion. Signicat provides libraries that will help you verifying the SAML using Java or C#.
- How to verify a SAML response using Java
- How to verify a SAML response using C#
- Links to the certificate if you use your own integration: SAML certificate
Retrieving attributes from the SAML response
Please refer to this overview of which attributes are available in the SAML responses.
Signicat Sign offer flexible solutions for electronic signatures and seals. The digital communication as well as exchanging of digital documents is increasing and the need of security likewise. Signicat Signature and Signicat Seal ensures document origin, integrity and non-repudiation.
Signicat Sign is a collection of advanced web services enabling companies to utilize electronic signatures in business processes. The services are hosted in a secure environment with redundancy and dynamic capacity. Recurring security assessments are performed and the services are audited by KPMG.
Getting started with Signicat Signature
The following is an introductory guide to understanding and getting started with Signicat Signature, the signature services we provide to our customers. For the sake of brevity, this document will link to a number of separate guides, examples and more exhaustive documentation when it is deemed necessary.
The commercial terms for using the services is based on a modular approach and this document does not consider pricing of the services, but only serves to provide a functional description of the services. Please contact your Signicat Account Manager for pricing details.
This guide has been sorted into the following sections — click each of them to expand:
When you start out with Signicat Signature, you are allowed to choose freely from the options offered in the following categories:
- Which signing method(s) to use
- Which functionality you require
- Customization options for UI and PAdES
We'll describe all three in detail below, as well as the Web Services allowing you to start implementing Signicat Signature:
Sign using Signicat Connect
Signicat Signature supports the use of any type of authentication method provided with Signicat Connect for applying the signature. Signing with Signicat Connect ensures a unified output format in accordance with EU specifications, and ensures a scalable, responsive signflow which supports almost any modern device standards and window sizes available for consumers today.
Signicat Connect allows you to choose from any of the following methods:
- Norwegian BankID
- Norwegian BankID Mobile
- Norwegian Buypass
- Norwegian Commfides
- Danish NemID
- Dutch iDIN
- Finnish TUPAS
- Finnish FINeID
- Finnish Mobiilivarmenne
- Swedish BankID
- Swedish Telia
- Estonian/Latvian EstEID
- Estonian/Latvian EstEID Mobile
- Social media
- YubiKey and YubiKey code
- Mobile ID
Sign using third-party methods
In addition to Signicat Connect, we also support signing performed with third-party methods. These do not follow the same output formats, cannot be guaranteed to support responsive signflows and will not necessarily support all of the signing functionalities.
Third-party signing can be provided with the following methods:
- Norwegian BankID
- Norwegian Buypass
- Norwegian Commfides
- Swedish BankID
- Swedish Telia
- Danish NemID
- Estonian EstEID
- Estonian EstEDI Mobile
- Spanish DNIe
The following functionality is supported, and may be utilized for signatures with Signicat Signature:
|Input document formats||Text and PDF.|
|Output document formats|
XAdES and PAdES.
The possibility to sign multiple documents. This also includes the option to sign all documents in a single operation.
It is possible to add multiple signers who may sign in any order or in defined sequences.
Notifications can be sent to users using SMS or e-mail in asynchronous signing processes.
|Viewer||A web application for viewing and verifying signed XAdES documents.|
|Document upload||Performed with our Session Data Storage as a part signing processes.|
|InkSign||A chainable method for adding electronic, hand-written signatures to your documents.|
|Forms||The addition of simple data forms for adding additional user information.|
We'll take a closer look at most of this functionality in the sections "Signature Requests step-by-step", "Signature Output" and "Features and Customization".
NOTE: When signing with a third-party method, the UI is partly defined by the provider and may or may not be responsive.
You will need to use Documentservice to integrate with Signicat Signature, with the other services below providing value-adding services to your document signature orders:
DocumentService is a service with a SOAP web service interface. It is used for creating and manipulating document orders for document centric services at Signicat. The service may be used from any platform capable of making a SOAP web service call. Signicat provides several connector kits with wrapper classes for accessing the web service. A connector kit may or may not be used when calling the service.
For customers using Java we recommend using our Java connector, which you can find more information about here: Signicat Connector for Java
For customers using .NET we recommend using a web service reference directly to the web services located on https://preprod.signicat.com/ws/documentservice-v3?wsdl. For production usage, the same wsdl can be used, but changing the endpoint to id.signicat.com or your subdomain will be neccessary.
Reference documentation for DocumentService can be found here: DocumentService v3 - API
Signicat SessionDataStorage Service
Session Data Storage (SDS) is a temporary storage for documents with a REST interface. It is used in conjunction with Signicat's SOAP services where it is necessary to upload and download binary documents. SOAP interfaces are not particularly well suited to send large binary data. SDS's REST interface is, on the other hand, designed specifically to provide a fast and efficient protocol for uploading and downloading binary data.
SDS is designed to work in conjunction with other web services. In a typical use case, the client first uploads a document using SDS and then calls a method on SOAP web service with a reference to the newly uploaded document. The web service may respond with a message that references another document that the client may download from SDS.
Reference documentation for SDS can be found here: SDS (Session Data Storage)
PackagingService is a service with a SOAP web service interface used for packaging one or more third-party SDO's into richer SDO's of different types. It may be used to package one or more third-party SDO's into a PAdES SDO, for example. The service may be used from any platform capable of making a SOAP web service call, and relies on Signicat's SDS service or Signicats Archive Service (configurable in the soap request) for uploading and downloading binary document data.
Reference documentation for PackagingService can be found here: PackagingService v4 - API
The ArchiveService API can be used to access documents that are stored in Signicat's archive. All documents in the archive are identified with a unique archive reference which is must be used to access the document. Documents has no metadata and there is no functionality for searching for documents.
Reference documentation for ArchiveService can be found here ArchiveService v3 - API
In order to make a digital signature, a signature request needs to be created. A signature request defines the instructions for the signature engine — in its simplest form it specifies what is going to be signed and how it can be signed.
The request is sent to the DocumentService web service, the URL for which can be found here (look for WSDL): DocumentService v3 - API
The typical lifecycle of a request is:
- Upload the documents to be signed to the Session Data Storage (SDS)
- Create a request with DocumentService
- Redirect the user to Signicat for the signing request
- Receive Status of the request
- Download the signed document from SDS
Due to the modular design of Signicat Signature, it is possible to deviate somewhat from this list — but for the moment we'll go through each of these steps in detail:
1 - Upload documents to be signed to the Session Data Storage
The SDS is a REST based interface where documents are stored temporarily. While it is possible to send the documents within the SOAP call made to DocumentService, it is generally recommended to use SDS for transfer of documents because SDS's REST based interface is more efficient and can deal with larger file sizes.
Instructions for using SDS can be found here: SDS (Session Data Storage)
2 - Create a request with DocumentService
A SOAP request needs to be made to DocumentService to specify the instructions for the request. Put simply, this is where you describe what to be signed, who needs to sign it and how they should sign.
Requests are made up of five main components:
More details about request creation can be found in the documentation: DocumentService v3 - API
3 - Redirect the user to Signicat for the signing request
When you want the user to start a signing action you will need to construct a URL leading the user back to signicat.
The URL will have the following format:
The red parts are as follows:
- env is the environment. When you're first starting out, this will typically be preprod — in production it will be id. In production, if you have acquired a Signicat Subdomain, this must be be used instead.
- service is the name of your service as registered with Signicat- There is a preproduction service called demo which you may use as you'd like, but eventually you will want to start using your own service.
- request_id is the unique identifier for the requests that was created.
- task_id is the unique identifier for a specific task in the request.
- artifact, optional, and should only be included if the return value from DocumentService createRequest includes an artifact, or if you specify an artifact later using DocumentServive createArtifact. This is a short lived Single sign-on artifact, valid for only 30 seconds, and can be used to secure the signature order if you prefer not to require the end-user to login with a stronger ID (such as BankId) to be able view the documents before signing. Please see How to use artifacts to secure document orders for a complete code example. Please also see the section Features and customization for a more thorough description of artifacts and their usage.
For a code example of a simple request using C#, see the following: How to create a simple document order with one subject and one document using Danish NemID
Request workflow and task order
The order in which the tasks of signature request is completed can be arranged by using "depends-on-task" within the Task datatype, allowing for complex workflows. For example: two customers and a salesman need to sign a contract, but the sales person may only sign when both of the customers have completed their signatures.
In this scenario the request would consist of three tasks (one for each signatory), so lets call them task A, B and C.
- first option is to let the two customers sign in parallel, this would be achieved by letting task C depend on task A and B
- alternatively all signatures could be sequential, this could be achieved by letting task B depend on A, and task C depend on B
Changing an existing request
There could be various reasons that you would want to change an existing request — the email address or mobile number of one of the signatories could have changed, the relevant signatories could change or the request could simply become obsolete.
- Existing requests can be deleted by using deleteRequest
- Notifications can be disabled and new notifications can be added to an existing request by using disableNotification and addNotification
- Tasks can be disabled and new ones added to existing requests by using disableTask and addTask
4 - Receive Status of the request
When the document order was created, you most likely defined a
documentactionrequest in order for notifications and callbacks to notify your server (or other recipient) about actions being taken by the signee — whether it's a request being created, cancelled or completed. We provide three complementary mechanisms for this:
- Notification by redirect
- Notification by server-to-server callback
- Notification by messaging
All are optional and may be used independently.
Notification by redirect
When you're creating a document order, the
documentactionrequest allows you to specify three different URLs where Signicat can redirect the end user when they have signed (or declined to sign) a document. These cover the following scenarios:
|The url where the end user should be returned when the task is completed.|
|The url where the end user should be returned if the task is cancelled.|
|The url where the end user should be returned if he chooses to postpone the task.|
URL is used when
The URLs are specified for each signature order, and may contain HTTP parameters with session specific or transaction specific values. The end user will not be redirected at all if on-task-complete is missing in the request when a document has been signed.
HTTP redirection cannot be guaranteed, however; the end user may close his browser before the redirect has completed or network problems may prevent the HTTP request to reach your server.
Notification by server-to-server callback
documentactionrequest allows you to specify a URL on your server that Signicat should call when a signature order is created or completed. Signicat's server will make an HTTPS call to this URL directly (or HTTP, but insecure HTTP calls are only supported in preprod). This is a server-to-server call, not involving the end user's browser at all. You may specify a static URL that should be used for all signature orders, or you may specify a different URL for each order. The URL may contain any number of parameters such as session specific parameters or user specific information. You may also add parameters for added security, such as a static or dynamic password. Signicat will always add the
requestId in an extra HTTP parameter.
The HTTP call will be made by Signicat's server and will come from a fixed IP address. In order for these to work, Signicat must be informed about the destination IP address and port on your end, as our firewall blocks notifications to unknown IPs by default.
The notification is specified in the request with these values:
|The URL that Signicat should call (with any HTTP parameters).|
|The string "URL"|
You may specify more than one notification if you want Signicat to make more than one callback. Delivery of the notification is guaranteed as long as your server is able to receive HTTP calls.
When doing server-to-server notification, you may choose to add additional security features to make the notification reliable. An example would be to:
- Create a one time token (a random number or string) for each request.
- Add the token to the callback url in a http parameter called i.e. "secure".
- When Signicat makes the callback, validate that the value of the parameter is correct.
This would protect against fake HTTP callbacks since senders of fake callbacks would not be able to guess the correct parameter value.
Notification by messaging
documentactionrequest allows you to specify a (mobile) phone number or an email address where Signicat should send a message when a document order is created or completed — you may specify one or more notifications like this. Typical uses of this is to send a message to a back office address, send a message to the end user or even send a message to a local workflow system. Each message is specified in each request, and the text can be personalized or contain user specific information like customer number, transaction details and so forth. Delivery of the notification depends on the SMS and email infrastructure and cannot be guaranteed.
The notification is specified in the
documentactionrequest with these values:
|Phone number (with country code prefix) or email address.|
|The sender address.|
|Subject in email. Not used for SMS.|
|The text message in the email or SMS.|
|The string "SMS" or "EMAIL".|
An example can be found here: How to notify and get notified when a document order status changes
Notes about security
You should not depend on the correctness of the information you get in the notifications. The notification should be regarded as a "hint" about a possible status change in the signature order. You must always call
getStatus on Signicat's web service after you have received a notification to get reliable, updated status information.
The "Notification by server-to-server callback" can be extended to include security mechanisms that would make the notification reliable. However, Signicat still recommends that you always call
getStatus to get reliable information. The information you get in return from the
getStatus web service call will always be correct and reliable.
Other web service calls
It is possible to get information about existing requests by using getStatus and getRequestHistory which, in combination, yields a precise picture of any given request's as well as related status events.
An example of this can be found here: How to check the status and result of a document order
NOTE: getStatus can be used for checking status on selected request, but in general, polling should be avoided. Instead, notifications and callbacks should be used.
5 - Download the signed document from SDS/Signicat Archive
In order to do this, you should know about the different formats the signed document may take. This will be described in greater detail in the following section: Signature Output.
With the signature request completed, the resulting file will vary depending on the eID infrastructure that produced the signature. Customers of Signicat have the choice of using the third-party output of the eID infrastructure, or use a packaging format like XAdES or PAdES which provides a number of benefits regarding security and usability. In this section, we'll explain the differences.
It is possible to select XAdES (XML Advanced Electronic Signature) as the output format of a signature. XAdES is an European ETSI standard that provides several benefits over most of the third-party output formats:
- One common format
- Supports Long Time Validation
- Contains relevant events related to the signature process
- Contains the certificate status response
It is possible to create a PAdES (PDF Advanced Electronic Signature) after a completed signature process. The PAdES file is a PDF compliant with the PAdES standard, which means that anyone with a regular PDF reader can see what was signed, by whom, and how it was signed. Evidence of every completed signature is embedded within the PAdES, which enables evidence to be unfolded in case of a dispute. PAdES files are made from packaging XAdES files — it is therefore required that the utilized signature method creates a XAdES output instead of the third-party format.
Benefits of using PAdES are:
- One common format
- Contains the full evidence of the signature
- Works as a container of multiple signatures on a document
- Can be read by anyone with a PDF reader
- Can be distributed to relevant third parties
- Enables all parties of the agreement to possess it
As mentioned above, utilizing PAdES requires packaging with our packaging service before the document may be handled further.
Our web service PackagingService is used to create PAdES files based on one or more XAdES (LTV-SDO) files. It is packaged according to the Packaging Policies specified for the relevant ID type. The source XAdES files can be referenced from a recent document order (OrderDocumentId), the Archive (ArchiveDocumentId) or from the Session Data Storage (SdsDocumentId). The resulting PAdES file is always retrieved from the Session Data Storage.
The following examples can help you get started with PAdES:
The third-party output of the various eID infrastructures is not standardized, which means that there can be several different resulting files. Looking at some of the Scandinavian eIDs; Danish NemID uses XMLDSIG as the output format, Norwegian BankID uses SEID SDO and Swedish BankID uses PKCS#7.
Information about the different eID infrastructures can be found here: eID infrastructures
In order to view, interpret and validate the signed documents, the third-party output format typically requires a solution such as Signicat Viewer. Furthermore, the storage of the combined proof of signature (which includes certificate status at the time of signature as well as transaction events) calls for an archive solution such as Signicat Archive, which is tailor-made for handling digitally signed documents.
Receiving and storing the signed document
There are two fundamental options for handling of the signed document: Sending it to the Signicat Archive for storage, or downloading it to your own systems (and subsequently archiving or distributing the document as desired).
Sending to Signicat Archive
It is possible to specify in the signature request that the result of the signature order should be sent to Signicat Archive using "send-result-to-archive", as described in the reference documentation: DocumentService v3 - API
Documents stored in the Signicat Archive can be fetched or deleted from the Archive using ArchiveService, described in further detail here: ArchiveService v3 - API
An example of how to specify that originals and signings results should be archived in Signicat Archive can be found in the following guide: How to use store originals and signed documents in Signicat Archive
Downloading the signed document
When the send-result-to-archive option is set to false, the documents will be stored in Signicats Session Data Storage instead. This is a temporary storage; documents can be accessed and retrieved for some time after the request is completed.
An example of how this is done can be found in the following guide: How to download a PAdES from SDS
Secure delivery of a PAdES document to an end user
Signed documents often contain sensitive information and it is therefore recommended that distribution of such document are made in a secure fashion. One way that this can be achieved is by making a request in DocumentService v1 - API where the PAdES document provided has the DocumentAction type of VIEW and where the end user is authenticated before he is allowed to view and download the PAdES document.
It is recommended that signature preservation is considered when signed agreements are of high value or if it is necessary to keep them over a longer period of time. Resignature of electronically signed documents can happen on documents in Signicat archive and on documents stored in your own organization.
The end user experience when signing documents with Signicat Signature can be customized a great deal — both when it comes to visuals and features. The following section will provide an overview of these options.
Portal and visuals
The portal is where the user meets the login and signature processes, it can be used standalone or embedded into a web site.
Graphical profiles are used to customize the visuals of the portal. Currently, this process has been standardized, allowing customers a baseline they are allowed to customize with backgrounds, logos and colors to their liking. More information about this can be found in the following section: How to work with graphical profiles.
All texts presented in the portal can be customized to fit the preferred languages of your company. While an array of different languages are already supported for different signature methods, you can request a CSV file from firstname.lastname@example.org with the current default values and change them as needed. More information about this can be found in the following section: How to customize and localize texts
Synchronous vs. asynchronous signature operations
Our definition of a synchronous signature is when the end user is already interacting with a website and, as a result of their actions — are sent to Signicat's signature environment. An example could be a user filling out a form which leads them to an agreement that needs to be signed.
There are three options when it comes to authenticating the user before they sign:
- Using a supported eID type
- Single sign-on artifact (SSO)
- No authentication
Instead of having to (re)authenticate the end user using an eID type when the user is redirected to Signicat, it is possible issue a single sign-on artifact (created in the request to DocumentService) which lasts for 30 seconds. This takes the form of a small text string which is appended to the task URL. When the end user is redirected to Signicat, the user will be authenticated and therefore does not have to login.
In order so maintain appropriate security, it is generally recommended that the end user is authenticated (either with eID or an artifact) before they are allowed to see and sign the document(s).
Our definition of an asynchronous signature is when the user is notified of a pending signature, and subsequently starts the signature process when they so desire. The user is sent a reference to the signature task either as a URL or a reference code that can be used to get to the task. The user can get access to the document with or without authentication with a supported eID method prior to seeing and signing the document.
Notifications to end users can be handled by Signicat signature services or by your own systems depending on your preference. You can choose to notify the user using DocumentService with either email or SMS notifications.
By default, the portal is located at https://id.signicat.com — but to give the best user experience (and to avoid browser alerts when iframing Signicat's solution into your web site) it is recommended to establish a subdomain. Signicat offers Signicat Subdomain, which allows customers to run their complete integration with id.signicat in their own subdomain.
These are some of the advantages of having a Signicat subdomain:
- As opposed to our standard solution, the log-in and signature web pages will appear to belong to the company itself. The end user will get the feeling of being on the same website when logging in or signing documents, and not sent to another unknown site during these processes. There is still a redirection, but it is less intrusive and will give a more unified user experience.
- The need for accepting third-party session cookies in the end users' browser disappears. Without the use of subdomain, third-party session cookie acceptance must be set in browsers when Signicat's authentication service is accessed through an iframe. (different isssues regarding the use of iframes is covered on this page).
For more information about setting up subdomains, please refer to the following documentation: Signicat Subdomain
Forms enable signatories to fill out a form and subsequently sign it with the ID method(s) specified in the request, allowing for simple forms to be filled as part of the signature process.
Forms are fundamentally comprised of an HTML form that is hosted on Signicats platform, as well as a PDF form in which the input from the signatory is merged into. The data that the user enters can be retrieved as structured data together with the signed PDF form. Multiple forms per service is supported.
For more information, please refer to the following document: Signicat Forms
An agreement often consist of more than one document, which is why Signicat Signature provides an efficient and user friendly user interface for digital signature of document packages with multiple documents.
The user interface is designed to provide an easy and secure user experience, guiding the user step-by-step with detailed instructions and simple choices. This increases the likelihood of users completing signature tasks, as well as decreasing the number of users contacting your support centre. The documents to be signed may be mandatory or optional —you may also include documents that should merely be opened and viewed.
Multiple document support is utilized seamlessly the same web service interface as single document signature flows — simply add the required tasks to the signature request.
More information about tasks can be found in the following documentation: DocumentService v3 - API
The user interface is designed to guide the user through a possibly complex process step by step. The user will always be presented for simple choices in a clear and informative way. They will also have the option to see through all the documents before they start signing the first document, and start over again if something goes wrong.
Mandatory and optional documents
You may tag each document as mandatory or optional. The user is required to sign mandatory documents and will not be able to proceed to the next document as long as a mandatory document is unsigned. An optional document may be skipped.
A document can be merely informational, and as such can be included only for viewing. These can also be tagged as mandatory or optional.
Focus on user confidence
The user may always choose to read through all documents before he starts to sign the first document. The signed documents are not delivered before the user has completed and confirmed by pressing the "Send in" button. The user may always choose to restart the process or simply refuse to sign. We believe that providing this as clear options increases the user confidence and actually increases the likelihood of the user completing the task.
Signature flows with multiple documents provide the same web service interface and integration techniques as single document signature flows, and as such is also based on neutral protocols like HTTP, XML and SOAP.
Packaging Service Templates
The packaging service will take one or more signed XAdES documents as input and produce one PAdES (PDF) document with a visual representation of the original documents and signatures. The resulting PAdES document may also include a description of the documents, signers and signatures. It is fully possible to customize the information that will be presented, as well as the graphical layout. This is done by defining one or more PDF templates containing dynamic fields, which are then merged with values from the incoming XAdES files, and combined to generate the resulting PAdES document.
Templates are configured into your Signicat service in communication with Signicat Operations.
More information about PAdES templates here: Customizing PAdES with templates
If you'd prefer to read the guide in a separate window, you can click here.
Packaging and archive
Más información | Més informació | More information
Requerimientos | Requeriments | Requirements
Java : Version 1.6.0 or above
Browsers: Chrome, Firefox, Internet Explorer 9 or newer
Java: Version 1.6.0 or above
Browsers: Chrome, Firefox
Other: OpenSC 0.13 or above
Mac OS X
Java: Version 1.6.0 or above
Browsers: Firefox, Safari
Other: OpenSC 0.13 or above
Spanish DNIe support
|Bank||Support tel.||Support||Support e-mail||Website homepage|
- Java - version 1.6.0 or higher
- Browser - Chrome, Firefox, Safari, IE9+. Internet Explorer 8 and below is unsupported.
Smart card software:
The signature applet uses different mechanisms to communicate with the smart card depending on the end user's operating system
Nothing needs to be installed by the user. Microsoft Crypto API (MSCAPI) is used, which installs DNIe drivers automatically. Documentation can be found at http://www.dnielectronico.es/descargas/windows.html.
|Linux / Mac OS X||OpenDNIe|
Installation packages and instructions can be found at http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/index.html. Some Linux distros have packages for OpenDNIe in their package repository. An example is some Ubuntu versions, where installation can be done by executing “sudo apt-get install opensc-dnie”.
|OpenSCversion 0.13+||Alternative to OpenDNIe. Support for DNIe is available in version 0.13 and above.|
It's important that OpenDNIe/OpenSC is installed with the same architecture (32bit/64bit) as the Java browser plugin. If not, the signature process will fail.
DNIe supports Spanish (Castellano), Catalan and English. The transactions can be started in any language and additionally it is possible for the end user to switch between different languages at runtime.
If you would like to change the texts in the authentication or signature processes, you may ask email@example.com to set up a localization module for you which can be used to translate the texts. An example of such a module is located at http://demo.signicat.com/dnie (the "L10N" option).