Skip to end of metadata
Go to start of metadata

Swedish BankID is a personal and an easy identification for secure electronic identification and signing on the Internet.

All individuals who have a Swedish personal identity and are registered in Sweden can obtain Swedish BankID through their bank. A BankID has the same value and used the same way, regardless of the bank that issued it. BankID may be issued to persons over 18 years, but several banks also gives BankID to persons under 18 years.

The banks issuing Swedish BankID

The banks issuing BankID to private individuals are Handelsbanken, SEB, Swedbank, SkandiaBanken, Lansforsakringar Bank, Danske Bank, Sparbanken Finn, Sparbanken Gripen and Ikano Bank. Together, these banks has more than 5.6 million Internet Customers who have the option of using their BankID in more than 300 different service applications.

Follow the links below for more detailed information about how to get started, the different certificates from Swedish BankID, the environments and screen dumps, which demonstrates the look-and-feel for the end-user.


 Test information



Test environment

Signicat offers 24/7/365 free access to the test environment,

Certificates for test user

If you already have an certificate for production BankID, you can login to and issue test certificates as explained below. This is also possible using an existing valid test-certificate.

Prepare a name and SSN for the testusers you would like to create. The SSN should be 12 digits, and a valid combination of digits. You can use to create a valid SSN for Sweden. You will get a number in this format: YYMMDD-XXXX. You have to change this to YYYYMMDDXXXX.

If you don't have a Swedish BankID, you may order a code from and issue new test-users accodring to "how to obtain the test user".

  1. If you do not have a Swedish social security number, you may construct one for test. This must be a properly formatted national ID including control digit. See:

How to obtain the test user

Go to this site: and log in with the option that suits you. also contain links and information about Swedish BankID and how to obtain test users.


There are four options:

  1. "Logga in med test-BankID" = Log in with a test-BankID.
    You can either log in with a test user on the computer or with a testuser using the mobile application you installed (that is if you already have a test user in the app/computer)

  2.  "Logga in med produktions-BankID" = Log in with a production-BankID. 
     If you have a Swedish BankID you can log in with your production BankID on the computer or in the production app (if you have set up the app to you BankID).

  3. "Logga in med personligkod" = Log in with a personal code. 
    If you don't have a personal code, you can choose to generate a new code.

  4. "Logga in med BankID på fil eller kort – Plugin" = Log in with a BankID on file or card – Plugin"
    Here you can use the old solution with plug-ins in the browser that will be phased out during 2014. This is the option you choose if you have BankID Security 5.0.2 or older.


After logging in you will be presented with this page. Choose to "Hämta BankID för test" :


At this page you can choose to download bankID for mobile(left) or desktop(right). Fill in the form with SSN, firstname and lastname, click "Hämta". 

Mobile client:

If you choose mobile bankID, you will get a activation code like this. (You must disable popup-blocker) This code is valid for 10 minutes

Open the BankID app on your phone, enter SSN and activation code. In the next window you create a pin code with at least 6 digits.

Done! Ready to use:


Desktop client

If you choose mobile bankID, you will be presented a new window. (You must disable popup-blocker) Press "Ladda ner BankID säkerhetsprogram" to download the desktop app.    


After its downloaded and installed, press "Hämta BankID". The desktop app should start automatically, if not you have to do it manually. (App name: Sikkerhetsprogram)

You will then be asked to create a password for your bankID. You have to remember this pin code because you will use it later when you test authentication/signing. The app will not allow you to choose a simple code like 111111 or 123456, so I would suggest using the birth date e.g. 180680.

Done! Your BankID is now ready:. 

If you have an ordinary or test BankID you may follow this recipe: 

  1. Access this site:
  2. Log in with your BankID and select "Hämta BankID för test". 
  3. You will receive an activation code which you may use in the BankID Säkerhetsapp.
  4. Select your securitycode for Mobilt BankID, minimum 6 numbers


If you don't have a Swedish BankID, you may follow this manual procedure:

  1. Send an email to (Financiell ID-Teknik) and describe where you work, the purpose of your development, and phone numbers.
  2. They will contact you and initiate creation of a test BankID. During this process you have to specify some data into the BankID Säkerhetsapp. They will verify that the newly issued BankID working.
  3. If you do not have a Swedish social security number, you may construct one for test. This must be a properly formatted national ID including control digit. See:



How to install the application (Android):

  1. To install the Swedish Mobile BankID application for test you first have to download it from this page:
  2. Under the header "Test av BankID" choose the  "Testversion BankID säkerhetsapp för Android" link and save the .apk file you get.
  3. Send the .apk file to your smartphone by e-mail.
  4. You have to allow the phone to install from unknown sources.
  5. Click the .apk file in your e-mail and install the app.
  6. When you open the app you need a Swedish National ID number (test) and an activation code


The installation file can be found here:


How to install the application (iOS):

  1. Install BankID säkerhetsapp from App Store.
  2. Then, go into Settings -> BankID -> Utvecklare (Developer) -> Server. Change this to

This setting makes the security app communicate with the test environment instead of production, and cannot be changed back. If you later need the production version, uninstall the app and install it again via App Store.



How to install the application (Windows Phone 8):

  1. Install "BankID säkerhetsapp" from Windows Phone Store.
  2. Start BankID Security App, select Settings / Developer / Server and enter "". 
  3. Save, exit BankID Security App and launch again. 
  4. BankID Security App will now connect to the test server.




How to install the application (Windows):

  1. Uninstall all previous versions of "Bankid säkerhetsprogram". Reboot PC.
  2. Download and install the latest version, available at:
  3. Find the config folder at this location: %APPDATA%\Roaming\BankID\

(Find appdata by writing %appdata% in the adressbar)


You will end up in the Roaming folder, so continue to the BankID folder. Your adress path should be someting like this now: C:\Users\Steffen(Your username)\AppData\Roaming\BankID

Here, you will find a folder named "Config". 


Rename this to "" and create a new folder named "Config"



Open the Config folder you created. Create a new .txt file and name it: CavaServerSelector.txt


Open it in Notepad, Write "kundtest" and save.

Restart PC and you are done!



How to obtain a Swedish National ID number:

To get a Swedish National ID number you can go to this page and generate one:


 For those who do not understand Swedish:

Födelsedatum = Birth date (ÅÅ-MM-DD) = (YY-MM-DD) as in year-month-day.

 Kön = Sex

 Kvinne = Woman

 Man = Man

Generera = Generate


The marked field is the generated National ID number. To use it for the purpose of authenticating/signing you need to remove the hyphen and add a prefix. The prefix should be the two first numbers in the year the person was born. So if the person was born between 1900-1999 the prefix is 19 and if the person was born between 2000-2099 the prefix is 20.

 The generated National ID number here: 800618-4629 would look like this: 198006184629 without the hyphen and with the prefix.



Swedish BankID, establishment

This is a process description for establishing a new solution with Swedish BankID.

The process describes the interaction between the Customer, the Customers Bank and Signicat Operations when developing and establishing a Web application, using Swedish BankID. The process contains descriptions of all the players tasks.

The process is described using steps, where each step has a natural end state. The descriptions are mainly superior and without technical details.

Signicat may, if the Customer expresses the desire for it, make some of the steps on behalf of the Customer.

Process overview:

  1. Customer signs agreement with Signicat AS
  2. Customer selects bank and signs an agreement with the Bank
  3. Customer performs technical integration with Id.signicat
  4. Customer orders Köparcertifikat for production from the Bank
  5. Customer performs "Köpargenomgöng"
  6. Customer receives and install the Köparcertifikat for production
  7. Customer performs the Köparcertifikat production test

End condition

At least one of the following functions must be available and successful in the Customers web application, using the Signicat services:

  • Secure identification of Internet users, using Swedish BankID
  • Digital signing of documents, using Swedish BankID


1. Customer signs agreement with Signicat AS

Signicat AS is a BICS supplier, approved by Finansiell ID-Teknik in Sweden.

The Customer signs an agreement with Signicat AS. This agreement specifies:

  • the SLA between the Customer and Signicat AS
  • the number of ID-methods (authentication, signing, verification, etc)
  • the number of ID-solutions (Swedish BankID, etc)
  • the number of graphical profiles the Customer needs
  • etc

2. Customer signs an agreement with the Bank or with Signicat about the use of BankID

This step takes place between the Customer and the Bank or Signicat.

If the Customer wishes to signed with a Bank, the following authorizations must be specified in the agreement:

  • Who is authorized to order, manage and close the Köparcertifikat certificate.
    • The Köparcertifikat represents the Customer, and is used to authenticate Internet users and signing of documents in real time.
  • Who is authorized to obtain and install Köparcertifikat for production environment.

If the Customer signs the agreement directly with Signicat, no paperwork regarding this step is required. This may speed up the establishment process with days or weeks. Signicat's Köparcertifikat will be used instead. 

3. Customer performs technical integration with Id.Signicat

After the agreements are signed, the Customer performs technical integration with Id.signicat. This includes:

  • Installation and programming with the Signicat client kit
  • Testing the integration

4. Customer orders Köparcertifikat for production from the Bank

This step is not required if the Customer has signed agreement with Signicat about the use of BankID.

The Customer creates a Certificate Request File (CSR-file) using the "Keyman"-software for the Customers Bank, and send an order containing the CSR-file via e-mail, to the Bank

Signicat has installed Keyman for different banks, and may, if the Customer wishes this, perform this task on behalf of the Customer.

5. Customer performs "Köpargenomgöng"

The Customer perform so-called "Köpargenomgöng" of technical and administrative solution with the Bank.

A Köpargenomgöng is a review of the Customers business:

  • In which service and how will BankID be used
  • Which BankID software will be used (Id.Signicat)
  • How is security implemented
  • Which logging routines exists
  • How are the requirements in the Privacy Act (Personuppgiftslagen PUL) handled
  • etc

Signicat may assist the Customer in describing the technical parts of the Köpargenomgöng-document.

6. Customer receives and install the Köparcertifikat for production

This step is not required if the Customer has signed agreement with Signicat about the use of BankID.

The Bank produces the Köparcertifikat and sends it to the person who is authorized to receive it.

When Signicat Operations receives the Köparcertifikat, it will be installed in the certificate archive according to Signicat's own safety routines for certificate management.

The certificate will be available in the Customers configuration on It will be used to authorize incoming transactions only from the Customers Web application, or a predefined white list of accepted sites which is specified by the customer.

7. Customer performs the Köparcertifikat production test

The Customer must notify the Bank three days before the production test will be conducted. The the date and time for production test and the number of identifications and signatures which will be made, must be specified.

The test is performed by using the Customers application. From the application, the identifications and/or signatures are sent to Id.Signicat. For each call, Id.Signicat creates a certain request, signs it with the Köparcertifikat, and sends it to the BankID server. BankID server receives this request, verifies it, and sends a response containing the result, back to Id.Signicat.

After finishing the test, the Bank analyzes the test results, and if it successful it sends an approval to the Customer. After approval is received, the Customer may launch the new Web application.




Köparcertifikat is a business certificate that can represent a company or an organization. A business certificate is intended to ensure communication to and from companies and organizations. It is not stored any personal information or personal identification in a business certificate.

The Köparcertifikat certificate will be stored in your system, or in the system of a service provider like Signicat AS.

BankID e-legitimation for private persons

BankID certificates are stored on smartcard or on a file on the end-user's computer.

Several Swedish banks are issuing BankID e-legitimation for private persons.

 Mobilt BankID
Mobilt BankID is a personal electronic identification for cell phones and tablets. It may be used from a mobile device in the same way as BankID on card or file can be used from a PC.
Mobilt BankID supports authentication and digital signature with Swedish BankID. It depends neither on a special SIM-card, nor on a specific telecom company. It is even possible to have Mobilt BankID without a subscription in a Swedish telecom company, but it can only be ordered by persons with a Swedish social security number. Mobilt BankID may be used from Android and iOS based phones and tablets (provided they have Internet access).

Today three Swedish banks are issuers of Mobilt BankID:

  • Swedbank 
  • Skandiabanken
  • Länsförsäkringar Bank
  • Several other banks plan to follow these three banks

Product info

The key features of Mobilt BankID are authentication and signature. In order to use Mobilt BankID, the BankID "Säkerhetsapp" must be installed on the mobile device.

With the BankID "Säkerhetsapp" it is possible to change the personal security code, change the language and pick up a new BankID via the banks online service.

It is possible to install only one BankID in each mobile device.

Signicat's Mobilt BankID signature method supports signing of both TXT and PDF format.

Signicat have not yet developed a viewer for BankID for Mobile. If it turns out that there is an interest for the product, we will consider developing a viewer also.

The technical integration with Signicat's Mobilt BankID service is identical with all other ID-solutions that Signicat support.

Getting started

For merchants:

Existing customers of Signicat may contact to find out what needs to be done to get up and running with Mobilt BankID.

For other customers the establishment process is identical with ordinary Swedish BankID. See a detailed description under certificates.

  1. You will need a merchant agreement with your bank.
  2. The bank performs a "Köpargenomgöng" of your company

After the agreements are signed and "Köpargenomgöng" is performed, the bank will issue a merchant certificate for the test and production environment.

For end users:

End users must install the "Säkerhetsapp" on their mobile device.

  • For Android users, the "BankID Säkerhetsapp" may be installed from Google Play.
  • For iOS users, the "BankID Säkerhetsapp" may be installed from AppStore.

External sources

Read more about Mobilt BankID on this page (in Swedish)


Login session

The pictures below illustrates the login process with Mobilt BankID

The user provides his/hers SSN.

The user provides his/her security code using BankID SäkerhetsApp on his/hers mobile phone or tablet.

The graphical style, language and text in this step may be customized.



Signature session

The pictures below illustrates the signature process with Mobilt BankID


The user opens and reads the document.

The graphical style, language and text in this step may be customized.

The user opens the PDF-document in a PDF-reader.

The user provides his/hers SSN.

The graphical style, language and text in this step may be customized.

The user provides his/her security code using BankID SäkerhetsApp on his/hers mobile phone or tablet.

The graphical style, language and text in this step may be customized.

 Screenshots of typical login and signing

This page contains screenshots of a typical login session and signature session. The actual screens may have a different graphical profile in your setup.

Login session

The pictures below illustrates the login/authentication process with Swedish BankID.


The user provides the personal password.

If the password was correct, then the user is authenticated


Signature session

The pictures below illustrates the signature process with Swedish BankID.

The user must read the content of the document. The user may have to open the document 
in a separate PDF viewer if the document is not plain text.

The user provides the personal password, and selects the "sign"-button.

The document is now signed.



 How to integrate with Swedish BankId from a native app


In May 2014, Signicat released a version of the Swedish Mobile BankID optimized for in-app usage. If you are building your own native app and want to utilize Swedish Mobile BankID authentication via Signicat, these are the required steps:

  1. Inform Signicat Operations that you would like to have a Swedish Mobile BankID method for in-app usage set up.
  2. In your app, you will perform a set of HTTP requests to Signicat in order to trigger and complete the process. Specifically, you will need to:
    1. HTTP POST the apiKey and (optionally) the personal number (SV. personnummer) to your service URL. Using cURL, the command would be something like `curl --verbose -H "Content-Type: application/json" -X POST -d '{"apiKey":"Bond007"}'`. The API key which will be given to you by Signicat Operations. In return, you will get:
      1. orderRef 
      2. autoStartToken
      3. The "collect" URL which you will call later to get the progress status of the authentication
    2. The autoStartToken received in the previous step is used to start the Mobile BankID app on the device when the "personnummer" is not given (ref. section 2a). Exactly how the app is launched depends on the operating system, so please refer to chapter 3.3 in the BankID Guidelines for detailed information.
    3. When the authentication is complete, the user will return to your native app. You will now need to HTTP POST the orderRef to the previously mentioned collect URL, which will tell you about the state of the authentication.
    4. Provided that the authentication is complete, you will receive a "complete" URL which you send an HTTP GET request to. This will give you the base64 encoded SAML assertion and target URI which you then HTTP POST to your server where it is validated and verified – exactly what you're doing if you already have an existing Signicat integration, so there's no need to change anything there.
  3. Most likely, you will want to exchange a valid SAML assertion for a cookie and then your app and your server knows the identity of the end user and you're good to go.


  • The first response from Signicat will contain a session cookie. This cookie must be used in consecutive requests.
  • Signicat will expect you to post your input as application/json in the request body, i.e. not application/x-www-form-urlencoded.

Example for Android

Please refer to for the complete source code of an example Android client demonstrating the steps outlined above.

Description of the Android App

The Signicat Swedish Mobile BankID Android App (referred to as the app or android app for the rest of this document) is a native Android app that demonstrates using Swedish Mobile BankId for authentication from a native app. It uses Signicat services and demonstrates a simple authentication scenario where the user enters his/her personal identity number, continues the process in the BankID app and finally returns to the app for completion.

 Detecting if the end user has the BankID app installed

From a native app

If you are writing a native app where you utilize Signicat services for your authentication or signature needs, then you will be able to detect if the end user has installed the BankID app necessary to complete the transaction.

Detecting on iOS

Please refer to Apple Developer Center for more information on canOpenUrl.

Detecting on Android

Please refer to Android Developer Center for more information about the PackageManager.

From a web page on a mobile device

Can't do it. And when you think about it, that's how it has to be, since otherwise it would be possible for any random web page to scan users' phones and tablets for which apps are installed, perhaps to target an attack against the user.

The good news is that you don't have to do anything about it, because Signicat already does its' best depending on the platform.

  • For iOS, an attempt is made to launch the app from javascript. If nothing seems to happen, a message is displayed saying that it seemed that the app couldn't be launched along with a link to the app store. 
  • For Android, a message is immediately presented to the user that the app is required to complete the process (along with a link to the app store), and then there is a button to launch the app and there is a button to cancel. If the user chooses to launch the app even though it is not installed, nothing happens. Presumably, the end user realizes the mistake and either proceeds to download the app or simply cancels.

Try it yourself

There is a demo page set up for Norwegian BankID which can be visited from desktop, iOS and Android and which will let you see for yourself how it responds. Please go to


Please contact if you have any further questions.

 Customizing the graphics and the flow for the end-user

In this document

Standard UI

By default, the module will have the following look:

This is the standard user interface, designed to be clean, clear and easily customizable. It has a responsivity breakpoint at 510 pixels – any browser window size below that and it will switch to a full screen layout. The following parts are customizable:

  • The logo
  • The logo size
  • The accent color (i.e. the header background)
  • The texts (in all languages)
  • The "help" link

Please contact for assistance in customizing the interface.

Graphical profiles

You may choose to embed the process in your own graphical profile, given that the following requirements are met:

  • No javascript allowed.
  • No external files (scripts, stylesheets, images etc.) allowed, i.e. all such resources must be provided to and served by Signicat.

Your graphical profile should look something like this:

A very simple graphical profile


        body {
            /* Just an example */
            background-color: #333;


Keep your graphical profile as simple as possible to reduce bandwidth and complexity. Make sure you test your graphical profile so that it doesn't interfere with the content provided by Signicat.

Iframe usage

If you intend to run the process in an iframe, you may choose to have graphical profile support disabled so you don't have to worry about it at all.

Important note for iOS9+

Please note that iOS 9 and later prevents apps from being automatically launched from an iframe. If you choose to iframe the process, then the module must be configured to ask the end user for his/her national id-number, after which the user must manually open the BankID app and then go back to Safari to complete the process. Full frame processes can automatically launch the app on iOS 9.

Custom styling

You may choose to switch off the standard UI, which will produce the same content – unstyled. It will then be up to you to write your own CSS in order to make it look the way you want. Here's how it will look without any CSS applied:

Behavior customization

The device question

By default, the module will ask the end user if he/she would like to use a BankID on this device/computer or a (mobile) BankID on another device. You may choose to have this question turned off, which implies that the user will always use a BankID on the local device or computer.

The id number

If the end user chooses to use a BankID on another device (see the previous section), then he/she must input her personal identity number (12 digits). The module accepts "prefilling" of the id number information, so if you already know the id number of the person then you may append the prefilled.subject=YYYYMMDDXXXXparameter to the request (or add it to the DocumentService request when creating a document order), in which case this dialog will be skipped.

Auto-launching the app 

In theory, the BankID app can be automatically launched on some platforms. The auto-launch feature is implemented using an invisible iframe which tries to load a certain kind of URL which will trigger the BankID app to start. Not all browsers support it – Chrome, for example, will disallow it from happening. If it seems that nothing has happened within five seconds after trying to auto-launch, then the interface will display a "Start the BankID app" button.

The auto-launching feature may speed up the process for users on platforms that support it, but it can also be a bit confusing and it will actually slow down the process for users on unsupporting platforms. Auto-launch is disabled by default. You may choose to have it enabled, but there are no guarantees that it will succeed.

Client flow

Given the customization points mentioned, the general client flow up until the BankID app is launched is something like:

The UX on mobile devices

In a browser on a mobile device

The BankID app is available for Android, iOS and Windows Phone.

On Android, the module can be initiated from any browser, and it will simply launch the BankID app and then return to the previous application.

On iOS, the BankID app must be told which URL to open once it's finished. The way iOS handles URL's is that it associates a certain "URI scheme" with a certain application, so for example URI's that start with "http(s)://" will be handled by Safari, "mailto://" by Mail, "bankid://" by the Swedish BankID app and so on.

There is no way to "close" an app programatically on iOS – you can only switch between applications by launching a URI. This goes for BankID too, so it must know which URI to launch once it's complete (referred to as the "redirect URI"). Now, by default, the Signicat BankID integration will try to switch back to the previously opened tab in Safari. The operating system does not guarantee that this will happen; it may launch a new tab and if it's running low on memory it may decide to reload the tab.

Signicat will handle try to handle this a graceful as possible, but there is one thing that can't be controlled: If the user starts the process in a non-default browser (such as Chrome for iOS or from within another app), then BankID will switch to Safari when the process is complete. Signicat will verify the transaction and redirect the user with a SAML response to the given target, but the end user will most likely notice that the "app context" was switched. Functionally, however, it will still be the same.

On Windows Phone, the behavior is similar to iOS, with the distinction that Internet Explorer will always be launched and it will always reload the page when returning from the BankID app (as of Windows Phone 8.0).

None of the mobile platforms allow a webpage to detect if a certain app is installed, for obvious security reasons.

In a native app on a mobile device

If you are building your own native app and you want to integrate with Swedish BankID from that app, you may choose to have the module set up optimized for "in-app usage". This will eliminate all UI, allowing you to communicate with Signicat with JSON request/responses and give you full control over the flow and user experience.

It's also possible to do the integration with an integrated browser control in a native app. On iOS and Windows Phone, you may choose to force a certain redirect URI either by having configure it for you, or you may pass the prefilled.redirect parameter with the (URL encoded) URI you want BankID to switch to. This can come in handy if you need the BankID app to switch back to your own app once it's done. The User-Agent header needs to indicate iOS (iPhone|iPad) or Windows Phone in order for this approach to succeed.

Browser support

Please refer to the Swedish BankID Q&A for more information on supported platforms. Please refer to the Relying Party Guidelines if you're looking for detailed technical information on Swedish BankID.

Test users

Please contact for more information on how to get certificates and apps for testing the service.

 Getting started with authentication

SAML 1.1 & SAML 2.0


Signicat offers authentication services using either SAML 1.1 or SAML 2.0. If you are using an identity federation service such as Microsoft ADFS or Oracle Identity Federation, then you are most likely interested in Signicat SAML2 gateway.

See the documentation for Signicat's SAML 2.0 interface if that is the case.


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.

  1. 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).
  2. 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.
  3. Receiving the SAML response: Signicat will then redirect the user back to your application along with the aforementioned SAML assertion.
  4. Verifying the SAML response: Your application will pick up the SAML assertion and validate it to make sure it's correct.
  5. 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:

where the red parts will depend on what you want to do:

  • env is the environment. When you're first starting out, this will typically be preprod, and in production it will be id.
  • service is the name of your service as registered with Signicat*. There is a demo preprod service called demo which you may use as you'd like, but eventually you will start using your own service.
  • method is the name of the id-method as registered with Signicat*. Common abbreviations are nbid for Norwegian BankID, sbid for Swedish BankID, nemid for Danish NemID, tupas for Finnish Tupas, esteid for Estonian ID-card and so on.
  • profile is 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.
  • language is the (ISO 639-1) two letter code for the language you would like in the user interface, such as nb for Norwegian, da for Danish, sv for Swedish, fi for Finnish, et for Estonian and so on.
  • target is 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/verify and 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.

Note that all URL parameters must be properly URL encoded using UTF-8, as per RFC 3986.

* 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 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


Host: localhost:8080
Proxy-Connection: keep-alive
Content-Length: 9213
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
SAMLResponse=PFJlc3BvbnNlIHhtbG5zPSJ1c...and so on and so on...Rpb24%2BPC9SZXNwb25zZT4%3D%0D%0A&TARGET=http%3A%2F%2Flocalhost%3A8080%2Fvalidate


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#.

  1. How to verify a SAML response using Java
  2. How to verify a SAML response using C#
  3. 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.

 Getting started with signatures

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.

Signicat Sign supports the use of any type of electronic identity method provided with our authentication product, Signicat Connect, for applying the signature. This 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.

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:


 Overview of Signicat Signature

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:

Signing methods

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
  • SMS
  • E-mail
  • 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

Signing Functionality

The following functionality is supported, and may be utilized for signatures with Signicat Signature:

Input document formatsText and PDF.
Output document formats
XAdES and PAdES.
Multiple documents
The possibility to sign multiple documents. This also includes the option to sign all documents in a single operation.
Multiple signers
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.
ViewerA web application for viewing and verifying signed XAdES documents.
Document uploadPerformed with our Session Data Storage as a part signing processes.
InkSignA chainable method for adding electronic, hand-written signatures to your documents.
FormsThe 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".

Customization options

Signicat Signature has a responsive UI — which means that the user interface will look nice and work normally across laptops, tablets and mobile phones. More information about customization options can be found in the section called Features and Customization further down in the document.

NOTE: When signing with a third-party method, the UI is partly defined by the provider and may or may not be responsive.

Web services

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 For production usage, the same wsdl can be used, but changing the endpoint to 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


 Signature requests step-by-step

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:

  1. Upload the documents to be signed to the Session Data Storage (SDS)
  2. Create a request with DocumentService
  3. Redirect the user to Signicat for the signing request
  4. Receive Status of the request
  5. 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:

  • Task(s)
  • DocumentAction(s)
  • Document(s)
  • Subject(s)
  • Notification(s)


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.

NOTE: all URL parameters must be properly URL encoded using UTF-8, as per RFC 3986.

Example of a valid signing url:

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. 

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:

  1. Notification by redirect
  2. Notification by server-to-server callback
  3. 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:

on-task-completeThe url where the end user should be returned when the task is completed.
on-task-cancelThe url where the end user should be returned if the task is cancelled.
on-task-postponeThe 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

The 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:

recipientThe URL that Signicat should call (with any HTTP parameters).
typeThe 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:

  1. Create a one time token (a random number or string) for each request.
  2. Add the token to the callback url in a http parameter called i.e. "secure".
  3. 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

The 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:

recipientPhone number (with country code prefix) or email address.
senderThe sender address.
headerSubject in email. Not used for SMS.
messageThe text message in the email or SMS.
typeThe 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.


 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.

Packaging service

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:

How to use the packaging service to create a PAdES from an LtvSDO

How to download a PAdES from SDS

Third-party output

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

Document handling

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.

Signature Preservation 

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.


 Features and Customization

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

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.

Text library

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 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).


How to allow anyone to view and sign the document

How to use artifacts to secure document orders

How to create and append new artifacts after the document order is created

How to require the user to authenticate before signing



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.


How to notify and get notified when a document order status changes



By default, the portal is located at — 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

Multiple documents

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


Wizard-like process

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.

Informational documents

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.

 Signing text documents with Swedish BankID

Swedish BankID natively supports signing of text documents in the BankID Security Application.

The technical requirements are that your text document is UTF-8 encoded and doesn't exceed 100 KB. Control characters such as TAB and CR LF are allowed.

See also BISP - beskrivning till förlitande part 2.2.pdf

The following is an example text document which is within the 100 KB limit.



Swedish BankID support

Support e-mailWebsite homepage

Other sources

  • No labels