Project and Integration Phases

Contract/ specification phase

282 views August 7, 2017 May 22, 2020 3

In the contract/ specification phase, the basis of the rest of the integration process is formed. Information needs to be exchanged, and several clarifications should be made. Generally, it is advantageous to get an overview and clarify tasks and issues as early as possible in the process.

Sales/ presales activities

Initial sales/ presales activities are usually handled by one of Signicat’s key account managers. They will inform the customer about relevant products, services and ID solutions.

If the customer comes to an agreement with Signicat, contracts will be signed:

  • The customer selects products, services and ID solutions, and signs an agreement with Signicat.
  • The customer signs an agreement either with the ID authority or Signicat for every ID infrastructure they want to connect to.

Clarifications with ID authorities

National identification numbers

National identification numbers (such as the Swedish personnummer or Norwegian fødselsnummer) are regarded as personal sensitive data in most countries. In order to obtain permission to use national identification numbers in applications, some ID authorities require that the customer has a a license or implements end-user consent in their application. Signicat informs the customer about these requirements, and how they can be handled.

Roles/ authorizations

Signicat’s roles and authorizations should be clarified in the agreements between the customer and the ID authority. The purpose is not only to secure and simplify the establishment process, but also future maintenance.

Roles and authorizations are not standardized among the ID solutions and may vary. One of Signicat’s Operations specialists may advise the customer in this regard. Typical authorizations are:

  • Responsibility to receive and install merchant, enterprise or SSL certificates
  • Responsibility to accept and sign ID-specific certificate tests
  • Responsibility to renew merchant, enterprise or SSL certificates
  • Responsibility to revoke merchant, enterprise or SSL certificates

Formal ID-specific approval

Some ID authorities require performance of formal ID-specific tests before merchant certificates for production can be issued. If necessary, Signicat may advise the customer about the procedures.

Authentication protocols

Signicat supports authentication protocols like OpenID ConnectSAML 1.1 and SAML 2.0. The selected protocol affects the configuration of the service, and if a client library from Signicat is needed or not.

Remark: It is quite possible to use a SAML client kit from other parties than Signicat. However, this requires that Signicat’s SAML signing certificate is configured with this client kit.

Security certificates

Several of Signicat’s products and ID solutions require the installation of security certificates that represent the merchant. Depending on products/ ID-solutions the customer has selected, the following certificates must be ordered and properly installed:

  • Most ID solutions require a merchant certificate issued by the ID authority.
  • Use of Signicat’s signature and archive web services requires client authentication of the customer’s application. A client SSL certificate for the web services, issued by Signicat, must be installed in this application.
  • Signicat’s subdomain product requires an SSL certificate issued by a certificate authority. This SSL certificate must be installed in Signicat’s production environment.
  • Signicat’s PAdES product may need an enterprise certificate for signing OCSP requests. This requirement applies to Buypass specifically.
  • Signicat’s SSO product requires a SAML signature certificate that represents the SSO partner. This certificate must be installed in Signicat’s production environment.

Configuration name

Each customer configuration in Signicat’s systems has a unique name. This name represents a company or merchant uniquely in our systems, and it will be used in a variety of contexts: in the technical integration, in the extranet, in the URL, in reporting, and in billing. This name should be as intuitive as possible. Signicat informs the customer about the use of this name, and suggests a suitable name for the configuration.

If the customer orders several subdomains, we will need to establish one customer configuration for each subdomain. This is due to system requirements.

Was this helpful?