The people behind RapidLEI came from the Certificate Authority world, we know it very well. I am credited with co-founding the CA/B Forum – the organisation created to try and introduce standardised vetting practices amongst all CAs in what is a traditionally self-regulating, self-auditing industry. The Internet has so much economic, communication and ethical reliance on CAs to get identity right in the Digital Certificates they issue, invariably the day finally came that all stakeholders agreed that standards were needed.
Whilst over the years CA’s provided some degree of transparency in their vetting processes via their Certificate Practice Statements, we all knew that ‘actual’ methods were never discussed in detail. It was only when we created the CA/B Forum that we managed to tease out best practice (and then only after the 2011 attacks on the industry created a sense of urgency and motivation).
After 100’s of ballots in CA/B Forum, the consistencies in process have been aligned and consensus reached. That took almost 15 years of effort but in the end, the resultant data is still not truly open and easily verifiable or challengeable. To get full visibility of identities within the Certificates you’d need to crawl the entire universe of issued Certificates, and even then, a great portion of these Certificates would exist in applications and networks that a crawler couldn’t ever see.
Of course, after the shock of seeing Symantec falling on its SSL vetting sword in 2016 and essentially losing the trust of the browser vendors, we can agree that the ecosystem is more open than it was, and with material consequences for poor process, but by no means can it be described as an open dataset.
Considering LEIs as a value-add to SSL Certificates
As someone that’s been so heavily involved in the CA/B Forum and greater CA world, all these reasons add to why I personally find LEIs so interesting. The obvious advantage the LEI ecosystem has over the SSL ecosystem stems from the Open Data Charter mandated by the regulatory oversight committee (ultimately endorsed by the G20). In total there are 71 regulators behind the system who are all very closely involved in setting standards.
The LEI system is completely open. In fact, on a daily basis anyone in the world can download 100% of the LEI data set and challenge any record. Does this mean the dataset is 100% accurate, unfortunately not. Some LEI issuers are clearly better at accuracy than others. But moving forwards, with a greater drive for accuracy (and consequence for inaccuracy), and with a formalised method for challenge the data quality will simply grow and grow in accuracy.
Crowd sourcing is obviously not the only way forward, so this year GLEIF are significantly increasing the due diligence on data, mapping codes, even spell checking cities. New API data checks will allow LOUs in real time to see if their data quality is good or bad at the point of issuance compared to the existing dataset and best practice, so this again will highlight flaws and guide future decisions.
The bottom line today is that there are errors in some records, but over time these are being squeezed from the system and the annual renewal will aid that process.
I should also add that the LEI data resides in a publicly accessible and challengeable database and can be updated daily should any company data change, while the text strings in a Certificate cannot change without reissuance. There is a real technical barrier here – unless you’re using a Certificate automation solution, reissuing Certificates on live systems represent real time investment and risk.
Background reference materials for further reading
The role of the LEI Issuer and registration Agents, validating the registrant data against authoritative sources:
GLEIF Registration Authorities List:
The established Data Quality program supports the validation rules:
Correct data formats and integrity are ensured via the LEI CDF and the usage of xml schema:
For more information around this subject feel free to get in touch with me and the RapidLEI team at email@example.com.