Skip to end of metadata
Go to start of metadata

Norwegian BankID is a personal and an easy identification for secure electronic identification and signing on the web. Norwegian BankID is offered and issued by the banks in Norway.

Norwegian BankID is based on a coordinated infrastructure that is developed by the banks through the Norwegian BankID Cooperation, under the direction of the "Finansnæringens Hovedorganisasjon" and "Sparebankforeningen".

In the middle of March 2015 it was issued person certificates (PersonBankID) to more than 3.5 mill different persons in Norway. The total number of BankID-transactions in Norway is between 0,9 and 1,0 mill each day.

Id.Signicat supports authentication, signing of documents and verifying of signed documents with Norwegian BankID.

Signicat has many customers in a wide range of different businesses, using Norwegian BankID for different purposes.

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

 Certificates

BrukerstedsBankID certificates

BrukerstedsBankID 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 BrukerstedsBankID certificate will be stored in your system, or in the system of a service provider like Signicat AS. A BrukerstedsBankID can be copied to other computers that you want to use.

BrukerstedsBankID certificate for preproduction

BrukerstedsBankID certificate for preproduction will usually Signicat's test merchant certificate for use in Signicat test environments. It may only be used to authenticate test users (not real live persons).

BrukerstedsBankID certificate for production

BrukerstedsBankID certificate for production represents your business in the BankID and Signicat production environments. This certificate will be issued by your bank, after you have performed the Merchant test, and sent a signed test declaration to the bank. It may only be used to authenticate real live persons (not test persons).

User certificate types

User certificates are "Banklagret", which means that they are stored centrally in the bank. It is possible to use a "Banklagret" BankID from any computer.

BankID has defined following types of client certificates:

  • PersonBankID which is a personal BankID which can be used both for authentication and signature.

Certificate policies

An issued certificate contains a reference to a certificate policy used when issuing the certificate. The reference is in the form of an OID located in the certificate policies extension. BankID has defined different policies for different types of subscribers:

Reference (OID)Certificate type
2.16.578.1.16.1.9.1Bank-stored end-user PERSONAL certificate
2.16.578.1.16.1.11.2.1Bank-stored end-user EMPLOYEE certificate
2.16.578.1.16.1.12.1.1Bank-stored end-user Qualified PERSONAL certificate
2.16.578.1.16.1.13.1.1Bank-stored end-user Qualified EMPLOYEE certificate
2.16.578.1.16.1.12.2.1BankID on Mobile end-user Qualified PERSONAL certificate
2.16.578.1.16.1.6.1.1Merchant soft certificate
2.16.578.1.16.1.6.2.1Merchant HSM certificate

User information

The user information available after a successful authentication may differ slightly between different issuers. Important parameters are:

  • National identity number (or social security number)
  • Name, full name or plain-name
  • Birth date,
  • Valid from,
  • Valid to,
  • Issued by.
  • PID, unique ID specific for Norwegian BankID

The user information available after a digital signature is the same as for an authentication. You will also be able to download the signed document. The signed document contains the digital signature produced by the user when he signed the document. This is sufficient for proving that the user actually signed the document.

The signed documents are represented in a SEID format, which is a Norwegian standard.

 Establishment

Establish a merchant application using Norwegian BankID

 

After signing a contract enabling usage of Signicat Services, Signicat Operations will start filling out necessary information to obain a agreement with you and Signicat for BankID dealer agreement.

Signicat Operations will handle all the technical details, as well as installation of the certificate.

 

 Test information

Norwegian BankID, test environment

Signicat's test environment preprod.signicat.com is available 24x7, and may be used during your developement and test phase. All use of this environment is free.

 Test BankID for merchants (BrukerstedsBankID)

Test BankID for merchants (BrukerstedsBankID) will be issued by your bank after you have signed the "Avtale om BrukerstedsBankID" (merchant BankID agreement).

Installation

Normally, a person at Signicat Operations will have the role as technical responsible in the BankID agreement. This person will receive instructions from the bank of how to activate the BrukerstedsBankID. When it is activated, it will be installed into the certificate store in Signicat's system, and made available for you from your unique customer specific configuration. When the configuration is set up in test, you may verify your merchant certificate by sending calls to the BankID authentication or signature service, using test users.

Test BankID for end users

There are two types of BankID for end users: PersonBankID and AnsattBankID. Both types are stored in the banking system, which means that there is no need for any certificate installation on the client. Access only requires that you have the social security number (personnummer), security code (sikkerhetskode) and a secret password.

You may order your own BankID testusers by sending an e-mail to support@signicat.com, and specify name and social security number for each test user. Signicat will forward this order to BankID Norway, and return the testusers to you as soon as they are available.

 

The file must be in CSV (comma delimited) or text format as below:

<originator>;<personal identification number>;<lastname>, <firstname>

Example: 9999;15098098745;Norman, Ola

Norwegian BankID Mobile test users

SIM cards for Norwegian BankID på mobil's test environment can be ordered via Signicat's Service Desk (by secure web form or by e-mail to support@signicat.com). The following information must be included:

  • Number of SIM cards needed
  • Size of SIM cards, either regular (most standard phones), micro (newer smartphones), or nano (currently only iPhone 5). Click here for a size comparison.
  • Which mobile provider(s) the SIM card(s) should be registered with.
    • The various providers are listed on BankID Norway's web pages (Norwegian).
    • If you have no preference, one will be selected for you.
  • Whether the SIM cards should be connected to existing test users.
    • If so, the names and national ID numbers of those test users.
    • If you have no preference, some user data will be generated for you.
  • Shipping address.
  • Billing address.

Signicat will verify the order and pass it on to BankID Norway. It will take approximately one week for the test SIM cards to arrive.

The customer is responsible for a device in which to insert the SIM card. BankID på mobil utilizes SIM Toolkit, so the device must support that. See BankID Norway's web page on the subject(Norwegian).

Browser/platform support

Support for Norwegian BankID are determined by several parameters. The most significant are:

  • Operating system
  • Browser
  • Support for Java and Java-version in the browser

For complete list of supported browsers, please visit this page on www.bankid.no (NB! In Norwegian language.).

 Production environment

This page contains relevant info when setting up a customer specific production environment with Norwegian BankID.

Testing your production certificates

When you have your own configuration on Id.Signicat, you may test your merchant certificate for production. The test can be carried out by authenticating real users, or signing documents on your configuration for production.

Norwegian BankID offers a test service where you may test your own PersonBankID. Please try it on this link

 Typical login and signature screenshots

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 Norwegian BankID:

Step 1: Provide social security number.

The user provides his/her social security number. If the SSN is already 
known, it is possible to prefill it, and skip this step.

Step 2: Provide code and password

The user provides a security code and a one time password, using a hardware token.

Step 3: Confirmation from BankID

A confirmation page tells the user when his/hers BankID was last used.

Signature session

The pictures below illustrates the signature process with Norwegian BankID.

Step 1: Read the document.

The user must read the content of the document. If the document is a PDF document, it will be opened in a PDF reader.

Step 2: Provide social security number.

The user provides his/her social security number. If the SSN is already know, it is possible to prefill it, and skip this step.

Step 3: Provide security code and password.

The user provides a security code and a one time password, using ahardware token.

Step 4: Get confirmation from BankID.

A confirmation page will inform the user that the document is correctly signed. The last OK button must be selected.

 BankID på mobil

BankID på Mobil

 

Product info

Signicat's BankID på Mobil service supports authentication and digital signature. The user must have subscription with an operator that supports BankID på Mobil. The BankID is connected with the SIM-card, and limited to only one BankID certificate pr SIM-card.

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

Getting started

New customers will have BankID på Mobil in their BankID-dealer agreement.

If you have BankID today, and wish to gain access to BankID på Mobil, please contact support@signicat.com.

External sources

Read more about BankID på Mobil on this page (in Norwegian).

 Getting started with authentication

SAML 1.1 & SAML 2.0

Icon

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

Overview

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:

https://env.signicat.com/std/method/service?id=method:profile:language&target=target

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 support@signicat.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.

Example

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:

https://preprod.signicat.com/std/method/demo?id=nemid:demo:da&target=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fverify

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.

Prefilling the ID-number

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=DDMMYYXXXXX parameter to the request (or add it to the DocumentService request when creating a document order), in which case this dialog will be skipped.

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

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

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

ArchiveService

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:

https://env.signicat.com/std/docaction/service?request_id=request_id&task_id=task_id&artifact=artifact

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: https://preprod.signicat.com/std/docaction/demo?request_id=10112015xwufkg8j94nfikhn0t26mvmme13mqzd37ok0tn5pv9am9y4hl&task_id=task0

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
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"
Attribute
Value


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".
Attribute
Value

 

 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.

Formats

XAdES

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

PAdES

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 support@signicat.com 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

Synchronous

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

Examples

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

 

Asynchronous 

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.

Example

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

 

Subdomain

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

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.

Integration

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 policy for Long Term Validation

Policy ID and location

Policy ID

urn:signicat:packagingpolicy:ltv:bankid-no:1.0:1.0

Name

Policy for Packaging of Norwegian BankID E-Signatures for Long-Term Validation 

URL

https://id.signicat.com/definitions/packagingpolicy/ltv-1.0/bankid-no-1.0


Introduction

This packaging service policy defines requirements for packaging of Norwegian BankID e-signatures for long-term validation in connection with the signature creation and initial verification. It includes requirement for collecting and packaging of the signers Norwegian national ID “fødselsnummer”.

About Packaging Policies

The purpose of a packaging policy is to specify requirements for the packaging process, and high-level requirements for the prior signature creation and verification process. 

The primary users of this policy will be e-signature users (relying parties). The policy will help e-signature users to better understand the information contained in a package, and on what basis it can be trusted and used.

The policy will also be useful for implementers of the packaging service.

Scope

This packaging policy defines requirements for packaging of Norwegian BankID e-signatures for long-term validation in connection with the signature creation and initial verification.

The policy also sets some high level requirements for the creation and verification processes, and requires them to collect certain data that is needed by the packaging process. 

The policy does not set detailed requirements for the signature creation and verification processes, because those requirements are controlled by BankID.

Structure 

The normative parts of the policy are listed below.

  1. General process requirement defines high-level requirements for the overall packaging process.
  2. Signature creation requirement defines requirements for the creation of the packaged signature (the “native” signature).
  3. Signature verification requirements verification defines requirements for the verification of the native signature. 
  4. Signature enrichment and hardening requirements  defines requirements for the signature enrichment and hardening process. 
  5. Package formatting requirements defines requirements for the format used for the package
  6. Sealing requirements defines requirements for the TSP signature on the package

Terms and acronyms

Term 

Explanation

TSP

Trusted Service Provider - the entity implementing this policy by packaging the signature.

Long-term validation

The concept of validating an e-signature long time (months, and some times years) after it was created. 

Native signature

The e-signature that is to be packaged for long-term validation

Original document

The document signed with the native signature

Signature enrichment

 

The addition of extra information about the document, the signer, the context or the signing and verification process. 

Signature hardening 

The addition of information that strengthens the non-reputability of the signature.

Native signature qualifying properties 

A common term for information that strengthens the native e-signature and makes it suitable for long-term validation.

Seal

This is the Trusted Service Providers signature on the package. It is commonly referred to as the Seal .

PersonBankID

BankID Personal certificate (Bank-stored end-user PERSONAL QUALIFIED certificate)

AnsattBankID

BankID Employe certificate (Bank-stored end-user EMPLOYEE QUALIFIED certificate)

MobilBankID

BankID on Mobile (Mobile end-user PERSONAL certificate)

 

References

Short name

Resource

XAdES

ETSI TS 101 903: “XML Advanced Electronic Signatures (XAdES)

SEID-SDO

SEID-SDO – Dataobjekt for langtidslagring og utveksling av elektroniske signaturer. Versjon 1 (in Norwegian)

General process requirements (normative)

  1. Packaging of the native signature is done such that it provides support for long-term validation of the native signature. 
  2. Packaging is performed immediately following signature creation and initial verification.
  3. Packaging is done only if initial verification succeeds.
  4. Validation data used in the initial verification is included in the package, to enable recreation of the validation process at a later point in time

Signature creation requirements (normative)

This section defines requirements for the creation of the packaged signature (the “native” signature).

  1. The signer's certificate must be of type PersonBankID (not AnsattBankID or MobilBankID).
  2. The original document can be either on plain text format or PDF format.
  3. Signature creation is performed according to the BankID requirements and guidelines at signature creation time. 
  4. Signature is created in SEID-SDO Basic-V format, and a SEID-SDO seal is applied.

Signature verification requirements (normative)

This section defines requirements for the verification of the native signature.

  1. Signature verification is done according to current BankID requirements and guidelines at signature verification time.
  2. The process will always include verifying that the cryptographic signature is created from the included original document, by using the signer private key corresponding to the public key in the included signer certificate. 
  3. The process will include certificate validation of the signer certificate, including revocation check. Trust anchors used in certificate validation are listed in Appendix A.

Signature enrichment and hardening requirements (normative)

This section defines requirements for the signature enrichment and hardening done as part of the packaging. 

Native Signature Qualifying Properties

The following information is included in the package as native signature qualifying properties:

  1. The trusted signing time, as collected by the TSP from a trusted time source.
  2. The Root BankID certificate of end-user BankID 
  3. The Root BankID certificate of the Merchant BankID (if different)

Signature creation context

The following information is collected from the signature creation context

Information about the client platform:

  1. Client OS and browser, as provided by the client browser.
  2. Client Java version

Information about the server platform:

  1. Server OS and Java version
  2. List of important server software components with versions

Signature verification context

The following information is collected from the signature verification context:

Information about the client platform:

  1. Client OS and browser, as specified by the browser through the HTTP Header “User-Agent”
  2. Client Java version

Information about the server platform:

  1. Server OS and Java version
  2. Version of the BankID API used, the “BankID Server”.
  3. List of important server software components with versions

Signature external context

The following information is collected from the signature external context:

  1. The description of the external context as provided by the user of the packaging service.

Additional information

The following additional information elements are collected:

  1. The signers FNR, by collecting it directly from the BankID VA service.

Audit trail 

Audit trail entries are collected for important events, for the purpose of strengthening the non-reputability of the signature, and to support forensics. 

 

Package formatting requirements (normative)

Package formatting is the process of putting all information elements together in a package.

Format

The package must be formatted according to the following format specification:

Name

Long Time Validation extended Signed Data Object 

Version *)

1.X 

Available at *)

https://id.signicat.com/definitions/xsd/LtvSdo-1.X

 

*) The 'X' means that the minor version number is not specified. In the URL, it should be replaced by the actual minor version.

Sealing requirements (normative)

This section contains requirements to the TSP signature on the package, also called the seal.

  1. The seal covers the complete package, such that all information in the package is protected by the signature.
  2. The seal is a XAdES signature.
  3. The signature is verified immediately following signature creation.
  4. Signature verification is done according to XMLDSig Core Validation [XMLDSIG]
  5. Verification includes certificate validation of the signing certificate, including revocation check. Trust anchors used in certificate validation are listed in Appendix B.
  6. All certificates and revocation values used in the initial verification of the signature are included in the XAdES structure.
  7. The signature does not include time-stamps.
  8. The package is signed according to an explicit signature policy which is available together with this policy. 

 

 

Appendix A: Trust anchors used in validation of the native signature

The following certificate is used as trust anchor in Certificate Path Validation and OCSP Response validation when validating the native signature. 

BankID Root CA 2048

-----BEGIN CERTIFICATE----- 

MIIDszCCApugAwIBAgIEPPtPMjANBgkqhkiG9w0BAQUFADBcMQswCQYDVQQGEwJO 

TzEjMCEGA1UEChMaRk5IIG9nIFNwYXJlYmFua2ZvcmVuaW5nZW4xDzANBgNVBAsT 

BkJhbmtJRDEXMBUGA1UEAxMOQmFua0lEIFJvb3QgQ0EwHhcNMDIwNjAzMTExMzU1 

WhcNMjgwNTI3MTExMzU1WjBcMQswCQYDVQQGEwJOTzEjMCEGA1UEChMaRk5IIG9n 

IFNwYXJlYmFua2ZvcmVuaW5nZW4xDzANBgNVBAsTBkJhbmtJRDEXMBUGA1UEAxMO 

QmFua0lEIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL 

xQpQGPCL28OPuPpLXkWuwk4AdrzGOuc2nHy1zkw43JNJp8xI7R7HTErbbvIPVJ8w 

WM9OV3v6nyJaNtEiLzOinj+oIwvNhx77wlU+99o/kcUyRmgRcEAR33LYVVG31nfN 

T3BZk8LaaClgEj+lBsfesGi+zdg+V0z9BtMgUM3u2Fow9Ed7RDmknbFhJAcJe9+2 

v1V1uIZYzVoYTG4f7biYjGHabK0KFR0jqTB6FUOZ3043bmpUIJQt3WhilaYUSeml 

BU8LorQgjmQb3N4udEPeo/LeTk7AUM77vJkcKHU+Sqc9+36eI2+HRz1eG7Khfiq5 

xrb1qyc100HOyc4KGKZ3AgMBAAGjfTB7MBIGA1UdEwEB/wQIMAYBAf8CAQEwFQYD 

VR0gBA4wDDAKBghghEIBEAEEATAdBgNVHQ4EFgQUaSQqxYzfDPewQDHgiboair3v 

ffswHwYDVR0jBBgwFoAUaSQqxYzfDPewQDHgiboair3vffswDgYDVR0PAQH/BAQD 

AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCigozPJX/BTayFp0SfFF3u0YoSTpUT9p+u 

l33iCbeldK3ba8BMtSgRLpdVhHaXIyoTyOwR43YuOyO7MHmBU+pEq7dRaEgj6Wn9 

YGjLLpFuVqU5tHcllYgJITLAMiDF5x9C2h2OXSebKTdWaw4H7O6SM7W0JyCNBmFQ 

29UbFr3P6ERYlj0p+Mh/WODgE+uSxwZxZ6+eMizRkrJGQgzhQAW+IB4jJ198SdDH 

r+npVmdSrL1v572KLKZaQjo1KiRmbltOMvXOw8uiq3ytULTNNaoSw+KIhh3gaWQU 

09yqg7tzqYRQ0Tm3ceQ5Es8f2FS/BdY07b3T3WQIExVuZtj93M0d 

-----END CERTIFICATE-----

 

BankID Root CA 4096

-----BEGIN CERTIFICATE----- 

MIIFsDCCA5igAwIBAgIBZDANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJOTzEj 

MCEGA1UECgwaRk5IIG9nIFNwYXJlYmFua2ZvcmVuaW5nZW4xDzANBgNVBAsMBkJh 

bmtJRDEXMBUGA1UEAwwOQmFua0lEIFJvb3QgQ0EwHhcNMDkwNDI4MTY0NTQ5WhcN 

MzUwNDI4MTY0NTQ5WjBcMQswCQYDVQQGEwJOTzEjMCEGA1UECgwaRk5IIG9nIFNw 

YXJlYmFua2ZvcmVuaW5nZW4xDzANBgNVBAsMBkJhbmtJRDEXMBUGA1UEAwwOQmFu 

a0lEIFJvb3QgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCHrO2o 

OJgH1XL6AF5BSTUwgZcMLaqsRzhWqWAFXgQZJliauDaGER4COVpEpk11mQBlk6AU 

EbTyeCJ9yl+Qfhw8zTv00/ZN6420y+e0Id3yX+kROIXj0f7+PQaOAv1d7GEYAPe3 

UaSk/unwyz2XWnPSHl4PUoxa3nqrJlhhhcVX5hJMxM9b8D3RsVhbY/XGPXe/wM2A 

bM3DRZjEkY/Bj1uAsphIzy8GroqDnsJ2OfhpiOvPSgR7Rv4ULf8YdzqRvn+j3awi 

fDVru1oMq5sVT2pO2iG9+vcuAEt6I6rdcGVNRSQc72o+Sj1MtnNI44CFSGVoluyu 

CvlNorHY4I0UuW+lndGy5t/icMeG2K4Wx5qfTLCIBqNMe3zQwtGuXa2hlRjFCuR/ 

UwOQV9a6NPKV7tnYXAV28FDqCLrfFzsHIdNtvoIUPYNQCUOukMEZlhO7B84vycI3 

DWBeiz7Ri/+R3fj4iD7/ySPqHqhAyyL4QfBc/OiP/lGWMBUPx7FK52k1PID3yhb7 

ZZAKLcnKn2Ok755fCMw3/SAlBAJwfuii8nwCOazYpJeIEuWVyZVttZpfDnw5IgoL 

DOGkopJfRAWaUdtlsuysGAOl/rZn02DnIcsIBwbC/Z+zpRr/c+Wa0h7PF1oTFpJ2 

uqDNv4zHXmGLcf6RTBJAmxMG/hH2n0cm0CJEvQIDAQABo30wezASBgNVHRMBAf8E 

CDAGAQH/AgEBMBUGA1UdIAQOMAwwCgYIYIRCARABBAEwDgYDVR0PAQH/BAQDAgEG 

MB8GA1UdIwQYMBaAFKBudPUx8LAUfeJ/P6bEfG/ZhGlcMB0GA1UdDgQWBBSgbnT1 

MfCwFH3ifz+mxHxv2YRpXDANBgkqhkiG9w0BAQsFAAOCAgEAZWrD+ZSuHskrIFCV 

T30RJwl73L38VF5RB++h4fBbujCswtEUM51VEK16/8tjZgp6dKpOp2MqIDGg2W87 

fBOI/7xR39RE+v92K5i6PRXhmnz97iPQUGqF6POyhDyuSIimrJnjw1WMd7LI1+FT 

3e/wdHV/WDTM5g0DV07McMGt29Ls4q/BDZtaXVUVI+SnpWtbBMHvCOt0JWjIcm4T 

6UG1WB9jeTYq5k4ikrwNUIbEwP2mtmPE30qYL/6DNFNMDLVziJhX5gjn+nMHwPBl 

biYbgMp47X5A79mfPLoQB0dZ82qAM8QqorVn88Y7IINOjR1Qvd0IWIiswEj2aVWf 

VSRZ20Zu/QTew4+sr1uIRqt2hs0+HIYr8ozNDbYh4Y/bu6BV6XYg1MTtto8lANPc 

mM9IXaDaDSZ79WPKxm4ltJC6bSYYRqbg8arVSQR4XwSt2bWyKJuiLg6i6wj4Msin 

l+toLDBezQWH9UcG3fB/rut5YTy10n03+m4l7nT/jDeLIZzRPdjnklUX/741FWK9 

27cra/wwZdgxRKA6oxHh2SpplgAtkeVZVe9bxKak1UGokOoPSOtaRzAf0UIpDQoh 

Euqk6ZRC2kMBrucGigaxJwLtbmlJeh9VG6eI/Ekzkhg/wu2+SNmdRF1dGZf1GA+x 

SEZSLzDXpRxX/9RbZ5VsPM3QF00= 

-----END CERTIFICATE-----

 

Appendix B: Trust anchors used in validation of the seal

The following certificates are used as trust anchor in Certificate Path Validation and OCSP Response validation when validating the seal (the TSP signature).

Buypass Class 3 CA 1

-----BEGIN CERTIFICATE----- 

MIIDUzCCAjugAwIBAgIBAjANBgkqhkiG9w0BAQUFADBLMQswCQYDVQQGEwJOTzEd 

MBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxHTAbBgNVBAMMFEJ1eXBhc3Mg 

Q2xhc3MgMyBDQSAxMB4XDTA1MDUwOTE0MTMwM1oXDTE1MDUwOTE0MTMwM1owSzEL 

MAkGA1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MR0wGwYD 

VQQDDBRCdXlwYXNzIENsYXNzIDMgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEP 

ADCCAQoCggEBAKSO13TZKWTeXx+HgJHqTjnmGcZEC4DVC69TB4sSveZn8AKxifZg 

isRbsELRwCGoy+Gb72RRtqfPFfV0gGgEkKBYouZ0plNTVUhjP5JW3SROjvi6K//z 

NIqeKNc0n6wv1g/xpC+9UrJJhW05NfBEMJNGJPO251P7vGGvqaMU+8IXF4Rs4HyI 

+MkcVyzwPX6UvCWThOiaAJpFBUJXgPROztmuOfbIUxAMZTpHe2DC1vqRycZxbL2R 

hzyRhkmr8w+gbCZ2Xhysm3HljbybIR6c1jh+JIAVMYKWsUnTYjdbiAwKYjT+p0h+ 

mbEwi5A3lRyoH6UsjfRVyNvdWQrCrXig9IsCAwEAAaNCMEAwDwYDVR0TAQH/BAUw 

AwEB/zAdBgNVHQ4EFgQUOBTmyPCppAP0Tj4io1vy1uCtQHQwDgYDVR0PAQH/BAQD 

AgEGMA0GCSqGSIb3DQEBBQUAA4IBAQABZ6OMySU9E2NdFm/soT4JXJEVKirZgCFP 

Bdy7pYmrEzMqnji3jG8CcmPHc3ceCQa6Oyh7pEfJYWsICCD8igWKH7y6xsL+z27s 

EzNxZy5p+qksP2bAEllNC1QCkoS72xLvg3BweMhT+t/Gxv/ciC8HwEmdMldg0/L2 

mSlf56oBzKwzqBwKu5HEA6BvtjT5htOzdlSY9EqBs1OdTUDs5XcTRa9bqh/YL0yC 

e/4qxFi7T/ye/QNlGioOw6UgFpRreaaiErS7GqQjel/wroQk5PMr+4okoyeYZdow 

dXb8GZHo2+ubPzK/QJcHJrrM85SFSnonk8+QQtS4Wxam58tAA915 

-----END CERTIFICATE----- 

 

 

Buypass Class 3 CA 1 - extended life-time

-----BEGIN CERTIFICATE----- 

MIIDUzCCAjugAwIBAgIBAzANBgkqhkiG9w0BAQsFADBLMQswCQYDVQQGEwJOTzEd 

MBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxHTAbBgNVBAMMFEJ1eXBhc3Mg 

Q2xhc3MgMyBDQSAxMB4XDTA1MDUwOTE0MTMwM1oXDTE2MDUwOTE0MTMwM1owSzEL 

MAkGA1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MR0wGwYD 

VQQDDBRCdXlwYXNzIENsYXNzIDMgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEP 

ADCCAQoCggEBAKSO13TZKWTeXx+HgJHqTjnmGcZEC4DVC69TB4sSveZn8AKxifZg 

isRbsELRwCGoy+Gb72RRtqfPFfV0gGgEkKBYouZ0plNTVUhjP5JW3SROjvi6K//z 

NIqeKNc0n6wv1g/xpC+9UrJJhW05NfBEMJNGJPO251P7vGGvqaMU+8IXF4Rs4HyI 

+MkcVyzwPX6UvCWThOiaAJpFBUJXgPROztmuOfbIUxAMZTpHe2DC1vqRycZxbL2R 

hzyRhkmr8w+gbCZ2Xhysm3HljbybIR6c1jh+JIAVMYKWsUnTYjdbiAwKYjT+p0h+ 

mbEwi5A3lRyoH6UsjfRVyNvdWQrCrXig9IsCAwEAAaNCMEAwDwYDVR0TAQH/BAUw 

AwEB/zAdBgNVHQ4EFgQUOBTmyPCppAP0Tj4io1vy1uCtQHQwDgYDVR0PAQH/BAQD 

AgEGMA0GCSqGSIb3DQEBCwUAA4IBAQCFpYJ6LryjhPCuxwMa6pdG+o9tLL1AgTUU 

WzJzPlbXKRJPkT60DiLptFhhcqu0/hEDz5hAkWXU6gydQlk3lZQodNLWj9Db+WyY 

casAxUSacqSuR/RT7G+myQEJ4Bl+4cBFjTY6McWCNifctCsJMhlNm3puHNytqwRy 

T2DoICHrURrzfaqnZ0hkNnf26Yhs0BDjWE/R+5SbzqmEVlLGVfZW8QzQMRNEnPkH 

Mg3Ah6doPqjO+1+UAJgeI+dC9epf+iQgGlBdzw3NLYtqbs3fsHu2/40bbOum0qfI 

Q8MLRyH/421x8g3MeJ7SAUQ8+fU5RzbkZUfnpGLIcH82viL3C9Pg 

-----END CERTIFICATE----- 

 

 

Buypass Class 3 Root CA

-----BEGIN CERTIFICATE----- 

MIIFWTCCA0GgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJOTzEd 

MBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxIDAeBgNVBAMMF0J1eXBhc3Mg 

Q2xhc3MgMyBSb290IENBMB4XDTEwMTAyNjA4Mjg1OFoXDTQwMTAyNjA4Mjg1OFow 

TjELMAkGA1UEBhMCTk8xHTAbBgNVBAoMFEJ1eXBhc3MgQVMtOTgzMTYzMzI3MSAw 

HgYDVQQDDBdCdXlwYXNzIENsYXNzIDMgUm9vdCBDQTCCAiIwDQYJKoZIhvcNAQEB 

BQADggIPADCCAgoCggIBAKXaCpUWUOOV8l6ddjEGMnqb8RB2uACatVI2zSRHsJ8Y 

ZLya9vrVediQYkwiL944PdbgqOkcLNt4EemOaFEVcsfzM4fkoF0LXOBXByow9c3E 

N3coTRiR5r/VUv1xLXA+58bEiuPwKAv0dpihi4dVsjoT/Lc+JzeOIuOoTyrvYLs9 

tznDDgFHmV0ST9tD+leh7fmdvhFHJlsTmKtdFoqwNxxXnUX/iJY2v7vKB3tvh2PX 

0DJq1l1sDPGzbjniazEuOQAnFN44wOwZZoYS6J1yFhNkUsepNxz9gjDthBgd9K5c 

/3ATAOux9TN6S9ZV+AWNS2mw9bMoNlwUxFFzTWsL8TQH2xc519woe2v1n/MuwU8X 

KhDzzMro6/1rqy6any2CbgTUUgGTLT2G/H783+9CHaZr77kgxve9oKeV/afmiSTY 

zIw0bOIjL9kSGiG5VZFvC5F5GQytQIgLcOJ60g7YaEi7ghM5EFjp2CoHxhLbWNvS 

O1UQRwUVZ2J+GGOmRj8JDlQyXr8NYnon74Do29lLBlo3WiXQCBJ31G8JUJc9yB3D 

34xFMFbG02SrZvPAXpacw8Tvw3xrizp5f7NJzz3iiZ+gMEuFuZyUJHmPfWupRWgP 

K9Dx2hzLabjKSWJtyNBjYt1gD1iqj6G8BaVmos8bdrKEZLFMOVLAMLrwjEsCsLa3 

AgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEe4zf/lb+74suwv 

Tg75JbCOPGvDMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAACAj 

QTUEkMJAYmDv4jVM1z+s4jSQuKFvdvoWFqRINyzpkMLyPPgKn9iB5btb2iUspKdV 

cSQy9sgL8rxq+JOssgfCX5/bzMiKqr5qb+FJEMwx14C7u8jYog5kV+qi9cKpMRXS 

IGrs/CIBKM+GuIAeqcwRpTzyFrNHnfzSgCHEy9BHcEGhyoMZCCxt8l13nIoUE9Q2 

HJLw5QY33KbmkJs4j1xrG0aGQ0JfPgEHU1RdZX33inOhmlRaHylDFCfChQ+1iHsa 

O5S3HWCntZznKWlXWpuTekMwGwPXYshApqr8ZORK15FTAaggiG6cX0S5y2CBNOxv 

033aSF/rtJC8LakcC6wc1aJoIIAE1vyxjy+7SjENSoYc6+I2KSb12tjE8nVhz36u 

dmNKekBlk4f4HoCMhuWG1o8O/FMsYOgWYRqiPkN7zTlgVGr18okmAWiDSKIz6MkE 

kbIRNBE+6tBDGR8Dk5AM/1E9V/RBbuHLoL7ryWPNbczk+DaqaJ3tvV2XcEQNtg41 

3OEMXbugUZTLfhbrES+jkkXITHHZvMmZUldGL1DPvTVp9D0VzgalLA8+9oG6lLvD 

u79leNKGef9JOxqDDPDeeOzI8k1MGt6CKfjBWtrt7uYnXuhF0J0cUahoq0Tj0Itq 

4/g7u9xN12TyUb7mqqta6THuBrxzvxNiCp/HuZc= 

-----END CERTIFICATE-----

 

Appendix D: Packaging Norwegian BankID Signatures for Long-Term Validation

This appendix explains how long-term validation concepts are applied to the packaging of Norwegian BankID e-signatures.

 

Trust anchors

trust anchor is a is an authoritative entity for which trust is assumed and not derived:

  1. The BankID Root CA for the end-user certificate, operating under a given certificate policy
  2. The BankID Root CA for the merchant certificate, operating under a given certificate policy
  3. The TSP, operating under this packaging policy 
  4. The CA of the TSP Certificate

 

Validation Data for the Native SDO

Validation data are additional data needed to validate the electronic signature, but which are not trusted in themselves.

For validation of the end-user signature:

ID

Information element

Were it is located in the package

Derives trust from

1

EU Certificate

In the SEID SDO

2,4

2

EU Intermediate CA Certificates

In the SEID SDO

3

3

BankID Root Certificate for EU Certificate

Native Signature Qualifying Properties

None. Trust anchor.

4

EU Certificate revocation data

OCSP response in the SEID SDO

5

5

OCSP Certificate

In the OCSP response in the SEID SDO

2

for validation of the merchant signature, and the SEID SDO seal signature:

ID

Information element

Were it is located in the package

Derives trust from

6

Merchant Certificate

In the SEID SDO

6, 8

7

Merchant certificate intermediate CA certs

In the SEID SDO

 

10

8

Merchant Certificate revocation data

OCSP response in the SEID SDO

9

9

OCSP Certificate

In the OCSP response in the SEID SDO

10

10

BankID Root Certificate for Merchant Certificate (may be identical to 3)

Native Signature Qualifying Properties

None. Trust anchor.

 

Validation Data for the TSP Signature

ID

Information element

Were it is located in the package

Derives trust from

1

TSP Certificate

In the XAdES Signature 

2, 4

2

TSP Certificate chain

In the XAdES Signature 

3

3

TSP Certificate Root CA

In the XAdES Signature.

None. Trust anchor.

4

TSP Certificate revocation data

OCSP response in the XAdES Signature

6

5

TSP Certificate chain revocation data

CRL in the XAdES Signature

7

6

OCSP Certificate 

In the OCSP response in the XAdES Signature

2/3

7

CRL Certificate for TSP cert

In the CRL in the XAdES Signature

2/3

 

Note: The validation data does not include revocation information for the intermediate CA certificates. This is because BankID does not provide such services (CRL or OCSP) for these certificates. This means that these certificate has a kind of trusted status, and that the compromise of their private key must be communicated out-of-band.

 

Trusted signing time

It is essential for Long-term validation to have a trusted signing time. Without this, it is impossible to decide whether the signing certificate was valid at the time of signing.

This packaging policy arranges for the following sources of trusted signing time:

  1. The TSP-collected trusted signing time included in the Native Signature Qualifying Properties. It relies on trust to the TSP trusted time source, and can be validated through validation of the TSP Signature.
  2. As additional evidence, the OCSP Response signing time is available, under SignatureDescription, and signed in the OCSP response. This can be validated as part of the OCSP response. Note that the relation between the OCSP response and the signature depends on trust to the TSP Signature and SEID-SDO Seal, and therefore on trust to the TSP and Merchant.

 

The Additional information will be

  1. The Norwegian “fødselsnummer”, as contained in the OCSP-response. This is contained in the signed End-User Certificate OCSP-response from BankID, and can be validated through validation of the OCSP Response, and the relation between the OCSP response and the end-user certificate.

External sources

Read more about Norwegian BankID on http://www.bankid.no (in Norwegian).