eID-Validation, e-Signature Verification


The amount of user interactions being conducted via the web is ever-increasing in the drive to provide efficient and cost-effective services to customers, employees, partners, citizens etc. However communicating over the internet requires trust in the electronic identity (eID) of the transacting parties. Only after such trust is established should access be granted to online systems and web-based resources, and only then should digitally signed agreements be accepted with confidence.

The use of PKI-based digital certificates is a long-accepted technique for managing electronic identities. It forms an essential element in securing communications channels within protocols such as SSL/TLS and IPSEC. Digital passports and citizen eID cards with embedded digital certificates that confirm the identity of the holder are becoming more common.

All these digital certificates need to be validated by relying parties since they may have been compromised or revoked after issuance. They also need to be checked because there may be a range of certificates issued by different issuers under different security policies to meet different trust levels. Deciding which digital certificates to trust can be a complicated task.

With regards to verification of e-signatures the complexities increase even further. There are many different signature and document formats, multiple ways of applying countersignatures, determining whether the signer was authorised to sign, historical verification of signatures, etc.

Ascertia provides products and solutions that answer these questions and remove the entire complexity of signature verification, certificate validation and trust management from business applications. Ascertia products and solutions are used internally with an organisation and by Managed Service Providers offering global verification services to multiple customer organisations.

Solution Description

Data received from customers, suppliers, partners, Governments and financial and legal institutions that have signatures attached should be verified immediately on receipt to ensure that trust can be established and audit trails kept. Signatures may be in a variety of formats including PDF, XML or PKCS#7/CMS. Documents may also be in various formats and include multiple signatures.

Used in this way ADSS Server can act as a pre-processor for existing business systems – checking that the data can be automatically processed or flagging via the business application that human intervention is required to resolve the trust issues found. Information can be returned from ADSS Server to the application showing the trust, quality status and other data from the digital signatures.

Systems that receive signed regulatory reports, e-invoices, orders, tender documents, etc need such a system to flexibly review and trust the signatures from various trust schemes.

Once the business application receives the signed data it can request ADSS Server to verify the signatures and establish the trust status for each of these. If they are good then automatic processing can be established with archived evidence of the verification process. If the signatures are unacceptable then the document can be filtered out for separate review.

Why Ascertia?

Signature Verification is rapidly becoming an over-used term. Many product and service providers claim to offer verification services to meet business needs. As trust solution experts Ascertia keeps being asked to explain the benefits that ADSS Server brings to an organisation as opposed to using alternatives such as open source toolkits, simple service models or limited function products. The answer is all about functionality, support for standards, security management, flexibility and investment protection. The following requirements are common to all Validation Service Providers

Verification / Validation Requirements ADSS Server Other Products
Can the solution process PDF, XML, S/MIME and other PKCS#7 and CMS signed documents? Yes Often limited to one or two formats
Can the solution handle basic signatures, timestamped signatures, long-term signatures, PDF certified signatures? Yes Usually a limited ability to cover this
Can the solution handle ETSI XAdES, CAdES and PAdES signed documents with support for multiple extended signature formats? Yes Often a limited capability
Does the solution allow the organisation to easily define the trust anchors (Root CAs and Issuer CAs) that are trusted? Yes Often limited to Windows trust lists
Can the solution verify multiple signatures in a single call and return information on each of the signers? Yes Detailed information is rarely returned
Does the solution support OASIS DSS protocol and DSS-X Verification Reports with the ability to offload application from complex coding? Yes A limited capability at best
Can the solution check both current and historic signatures and after a grace period, using a specified time in the past? Yes Historic signatures are rarely handled
Can basic signatures be enhanced to long-term signatures (CAdES and XAdES) as part of the verification process? Yes Usually a limited ability to cover this
Can the solution keep old CRLs from each trusted CA so that these can be used to check the signature status in the past? Yes Rarely seen
For long-term signatures can the solution automatically use the embedded CRL/OCSP information if valid? Yes Often a limited capability
Does the solution have effective role based access security controls and maintain protected event and transaction logs? Yes Check carefully this is rarely seen!
Can a high availability load-balancing configuration be immediately deployed? On platforms other than Windows? and supporting a range of HSMs? Yes Most have issues being this flexible!
Can CRLs, OCSP, XKMS or even SCVP services be used to check the signer’s status? Can a sophisticated validation policy be configured to define the order in which these mechanisms are used, and how to locate and communicate with the back-end status providers? Yes CRL is common OCSP is rarer Support for XKMS and SCVP is very unusual
Can optionally a copy of the original document be kept within the solution’s transaction logs as evidence? Yes Usually a completely separate action
Can a notary archive action be associated with the verification action such that a long-life archive signature and timestamp are applied within an LTANS compliant archive? Is a TSA and LTANS service provided as part of same product. Yes Usually a completely separate project or product Support for LTANS very unusual
Verification / Validation Requirements Yes Usually a completely separate project or product
Is there a solution option for extracting and sending only the signatures from documents to ensure privacy at the relying customer? I.e. is a gateway type product provided? Yes Most have issues being this flexible
Is the solution designed to be used by both end-users, business relying parties and managed service providers? Yes Often a limited capability
Does the solution provide detailed logging of each transaction, the evidential information & filtering/searching? Yes Often a limited capability
Does the solution provide an in-built capability for service reporting (detail and summary reports)? Yes Often a limited capability
Can the calling client applications be authenticated using request signing and/or SSL client certificates? Can these clients be limited to only use specific signature verification profiles? Yes Most have issues being this flexible
Can the solution provide a standard based approach to providing quality information on the signature algorithms, key lengths, hash algorithms and certificates associated with the signature and whether these meet the minimum local security policy requirements of the relying party? E.g. are the PEPPOL specifications supported? Yes Rarely seen
Does the solution provide a Client SDK for Java and .Net environments plus source code samples and example applications to make integration really simple? Yes Worth checking
Can the solution be created on Windows, Solaris and Linux platforms with support for 32 and 64 bit processing? Yes Worth checking
Are various FIPS 140-2 level 3 or CC EAL4 HSMs supported? Yes Worth checking
Is an effective security management environment maintained that protects the authentication mechanisms, the verification policies, the validation policies, the keys, certificates, operator and system event logs and the transactional logs? Is it compliant with CWA 14167-1 Requirements for Trustworthy Systems? Yes Worth checking

ADSS Server enables organisations to check transactional validity at the server. Some people advise allowing the end-user to determine if the data is to be trusted, however Ascertia does not recommend this approach – if the data cannot be trusted then why present it to busy managers?

As can be seen ADSS Server has been designed to cope with a changing e-business world in which multiple document formats will be used, with multiple signature formats and other properties. Although requirements may seem clear now there is usually a clear need for investment protection so that changing business requirements do not lead to a project being scrapped and restarted because of a lack of flexibility.

ADSS Server was selected as the core technology of the DNV Validation Authority Service (http:/www.dnv.com) after an open global tender – our approach and product functionality and flexibility was our key to success. BBS (http://www.bbs.no) now runs this service and has renamed it as the Global Verification Service.

Request Info


Sales Inquiries:
+44 (0)800 772 0 442


Years of Digital Signature