Project and Integration Phases

Contract/specification phase

69 views August 7, 2017 November 6, 2018 0

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. He/ she will inform the customer about relevant products, services, and ID-solutions.

If the customer agrees with Signicat, contracts will be signed:

  • The customer selects products, services, and ID-solutions, and signs 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-authority

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 could 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 the 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. This requirement applies to the following ID-solutions:

SAML protocol

Signicat supports two different protocols for the authentication service: SAML 1.1 and SAML 2.0. Normally the customer selects SAML protocol according to own policy and technical platform. The selected SAML 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 require 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 sub-domain 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.
  • 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 suggest a suitable name for the configuration.

If the customer orders several sub-domains, we have to establish one customer configuration for each sub-domain. This is due to system requirements.

Was this helpful?