Although it may seem surprising, one of the main new features of the next Viafirma 2.2 version, which will be released in a few days, is its integration with the @Firma v5 platform.
For the reader who does not know @Firma (also known as aFirma), it is a platform with similar functional characteristics to Viafirma, having as main responsibilities to provide third party applications (which are integrated with @Firma through a client API) the support of authentication and digital signature with digital certificates. Its development was led by the Junta de Andalucía, where it is the corporate platform for authentication and digital signature, and it has also been chosen by the MAP (Ministry of Public Administrations) as its base tool for this type of functionalities, ceding its use to any Spanish Public Administration. We speak therefore without any doubt of a platform with a great relevance in the market and a more than significant number of implementations.
Why do we say that this new Viafirma’s functionality “may seem surprising”? Well, because, as the reader will have noticed, in principle Viafirma and @Firma “are dedicated to the same thing”, that is to say, to provide authentication and electronic signature support to applications. Then, why integrate both platforms?
The idea of their integration arises from the possibility of isolating responsibilities within the authentication and digital signature process, making both platforms interoperate in a SOA environment and take care of each of the functionalities in which they excel. In our company, VIAVANSI, we have developed a great multitude of applications that integrate with @Signature for the Regional Government of Andalusia. Perhaps we could highlight some weaknesses that from our point of view we have noticed in this platform:fi
- Its compatibility matrix (as of today the last one can be consulted in this link of the Regional Government of Andalusia’s Pluton portal) is relatively reduced for the Public Administration, which seeks to provide service to 100% of the citizenship. For example, Mac users are left out of it (like this writer), we have observed problems depending on the JRE versions, there is currently no support for Firefox 3, etc.
- The appearance (look & feel) of the client can be improved.
- Each application that integrates with @Signature must have the @Signature client in its libraries, and develop code to use this client. This implies that, every time there is an update of this @Signature client, it is necessary to make a significant effort in application maintenance to introduce the new client, make the necessary changes, test and deploy the applications again, etc.
Precisely, these weaknesses are in fact Viafirma’s strong points, which make it stand out. Maybe because it is a more recent development platform, Viafirma has a huge compatibility matrix, being able to operate in almost any combination of operating system / browser / Java Runtime Environment (JRE) version / certification authority / certificate disposition (software, card -DNIe-, token)… For example, signing on Mac without problems 🙂 As an example, in the first two weeks of operation in the application “Company training actions” of the Tripartita Foundation for On-the-Job Training, the number of authentication and digital signature operations exceeded 300,000 with almost no incidences. In fact, the “Training Actions for Companies” system is probably, together with the Tax Agency’s Income Tax applications, the public application with more digital signature operations in Spain, since practically any Spanish company can be a user of the system.
On the other hand, Viafirma includes a “push” concept of its signature client, which is a crucial advantage for the application maintenance strategy. The client library resides in a single central node (Viafirma’s server), so that when a new version of this library is released, the update must only be done in that node. All the applications that use the client are automatically updated at that moment, reducing enormously the impact of the new developments. Undoubtedly, this avoids update failures that are difficult to control, and all these advantages are finally passed on to the citizens, who in any case are the users of these systems.
This new feature of Viafirma 2.2 allows using the platform for the operations more related to the application user (the detection and reading of certificates, and the digital signature operation in local). Viafirma communicates with the native Web Services API’s of @Firma for the rest of the core operations: the validation of certificates with the CRL’s or OCSP services of the different certification authorities, the custody of the signed documents, etc.
This way, a fast and non-intrusive integration in “bridge mode” is achieved. It could be said that Viafirma is in charge of the “client layer” of the process, interacting with the user and its certificate store, and @Firma is in charge of the “server layer”, being responsible for the connection with the different CA’s, the custody of the signatures (optionally), etc.
The advantages of this scenario are thus many:
- The institutions have a universal signature client, which supports practically any combination of operating system (Windows, including even the beta of Windows 7, Linux, Mac OS), browser (Internet Explorer -6, 7 and even the new version 8. …-, Firefox-including version 3-, Safari, Google Chrome…), JRE version (5, 6, etc.), CA’s (FNMT, eID, Camerfirma, ANCERT, Izenpe, Firma Profesional, ANF-AC, etc.), dispositions (software, card including eID, token, etc.)… The compatibility matrix is greatly expanded, with citizens being the main beneficiaries.
- Viafirma’s signature client even supports the use of a certificate exported in P12 format (usual export format in Linux or Mac) or PFX (the latter is typical in Windows), without the need to import it in the certificate store of the operating system or browser. A typical use case would be, for example, that we have our personal certificate exported on a USB flash drive and we want to perform an authentication or digital signature operation in a cyber-café, where we may not have permissions to install the certificate (or simply do not want to for security reasons). The user can choose the location of the P12 or PFX file from a local path (for example on that USB flash drive), and use it as if the certificate were installed on the machine.
- The cost of application maintenance is greatly reduced, since, as mentioned above, the signature client only resides on a central node and the client version update is performed automatically in the applications.
- It creates an arrangement fully consistent with a policy of interoperability between platforms based on SOA architectures, taking advantage of the strengths of each of them, arranged as a service.
- It creates an arrangement fully consistent with a policy of interoperability between platforms based on SOA architectures, taking advantage of the strengths of each of them, arranged as a service.
Viafirma’s new version 2.2 also supports the CMS format and the 3.1 e-invoice format and includes other minor updates.