The Safelayer platform can be seen as a set of service components, accessible as Web services, that implements certification and digital signature functions, data encryption and the required auxiliary protocols involved in the deployment of applications using Public Key Infrastructure (PKI) services. These functionalities can be divided into different types of services:

  1. Key management. Registration, revocation, retrieval and verification services.
  2. Objects and entity Management. Registration, retrieval and modification of information regarding objects and entities, in particular, identification information.
  3. Registered entity authentication, authorization and access control services.
  4. Digital signature. Digital signature generation and verification services.
  5. Digital encryption. Data encryption, decryption, enveloping and deenveloping services.
  6. Digital non-repudiation. Digital evidence generation and validation services generally accompanied by digital signature.

In general, the above groups cover basic security services: Identification (1, 2, 3 and 4), Integrity (4), Confidentiality (5) and Non-Repudiation (4 and 6). And other services such as: Authorization and Access Control (3), on which Single Sign-On (SSO) can be built.

Services are implemented according to standard specifications, either consolidated or in the process of becoming consolidated. This guarantees future continuity (protecting investment) and external system interoperability. The following access protocols have been chosen for the previously mentioned services:

  • Key management: XKMS (XML Key Management Service).
  • Objects and entity management: XML/XPath, entity patrons based on Liberty Alliance ID-SIS (Identity Service Interface Specification).
  • Authentication, authorization and access control services. ITU-T X.509 and SAML (Security Assertion Markup Language) as Secure Token Services (STS) as is defined by OASIS WS-Security and compatible with WS-Trust and WS-Federation. Access control will be based on OASIS XACML.
  • Digital signature: OASIS Digital Signature Standard (DSS).
  • Digital encryption: this is proprietary as there is no standard.
  • Digital non-repudiation: OASIS Digital Signature Standard (DSS) and XAdES.

This basic set of services can be complemented with other services as long as they comply with Web Services integration rules. Certain services can be obviated if they are not required in certain application environments.

TrustedX Architecture

The TrustedX platform consists of a set of service components that handles all the above-described functionality. The components are as follows:

  • TrustedX Authentication & Authorization (TWS-AA). Authentication and Authorization service that includes authentication mechanisms using login/password and digital certificate (TLS/SSL), both used in a direct standard manner, as well as additional mechanisms based on signatures with X.509 certificates.
  • TrustedX Entity Profiler (TWS-EP). Information management service providing uniform object and/or entity profiles: users, applications, Web services, policies, certificates, logs/audits, etc.
  • TrustedX Digital Signature (TWS-DS). Document digital signature service allowing the generation of different recognised basic signature formats (PKCS#7/CMS, PDFDsig, CAdES, XML-DSig/XAdES and S/MIME).
  • TrustedX Digital non-Repudiation (TWS-DR). Advanced digital signature service adding reliable time and revocation information to previously signed documents as a basis for long-term digital signatures.
  • TrustedX Digital Signature Verification (TWS-DSV). Digital signature verification service (including advanced or long-term digital signatures) regardless of the supplier, or the digital certificate and signature format verification mechanisms.
  • TrustedX Data Signature Custody (TWS-DSC). Custody service for the digital signatures of documents that maintains their validity for long periods of time, thus implementing long-term digital signatures.
  • TrustedX Digital Encryption (TWS-DE). Document encryption and decryption service in PKCS#7/CMS and XMLEnc formats.

The TrustedX platform provides a common management system including configuration, monitoring and access control for each service component. The system presents the following features:

  • In order to maintain an open and customizable architecture, XML language is used for configuration, customization, monitoring, audit, and control data. This applies to any type of data stored or exchanged at control ports of online services. TWS-EP is the service component dedicated to this function.
  • Services are accessed through SOAP according to the WSDL specification of each particular service. Access is controlled using an authentication Token that has previously been requested from the TWS-AA service. The client-server interaction is performed via HTTP or HTTPS transport thus enabling the channel to be secured with SSL/TLS with or without mutual authentication. For example, if a login / password authentication is requested, it is recommended to use SSL/TLS.

Each TrustedX service component can interact with other infrastructure elements, whether corporate or external, namely:

  • Trusted Third Parties, to which TrustedX connects to validate the digital certificates (Certification Authorities or Validation Authorities) and to obtain time-stamps (Time-Stamp Authorities). For example, trusted third parties may be implemented with Safelayer’s KeyOne product family - KeyOne CA, KeyOne VA or KeyOne TSA.
  • TrustedX can operate with an external cryptographic device (HSM) (not shown in the figure).
  • Database, where TrustedX stores log information relating to the activity of the TrustedX platform’s service components for later auditing.
  • Document Management System (DMS/ECM), where the electronic signature custody service component can store and manage the documents with signatures, and the encryption component can store ciphered documents.
  • Directory, where the TWS-EP service component can read and write information about the entities (individuals, applications or Web services) recognised by the platform.

In future versions of TrustedX, it is planned to incorporate the capacity to interact with the below components:

  • Policy Decision Point (PDP), is an optional external service in which TrustedX can delegate the powers of providing decision policies, thus determining the access rights of an entity to a resource.

The below figure shows details of the interaction between the mentioned infrastructure elements with TrustedX and with the corporate applications that use the TrustedX services. There is also the option, especially the greater the number of applications and/or if different authentication mechanisms are required, to have available an authentication/authorization agent to centralise some or all of the authentication and authorization functions required by the applications.


architect1 en
Figure. Interaction of the TrustedX platform with external components.

We use cookies to improve our website and your experience when using it. Cookies used for the essential operation of this site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.I accept cookies from this site