Why Can’t Documents Be Secure, Like Databases?
Continuing the series on changing the business reporting supply chain, and the goals I sought to achieve leveraging XBRL that have not come to fruition during XBRL’s first 20 years, I come to this item from the August 18 blog, “Security methods, including selective encryption, for selective unfolding of single documents to different stakeholders – one version of the truth.”
I wanted to use digital signatures for trust and accountability, traceable – as appropriate – from first transaction to end report.
I wanted to use encryption so the right people could get the message, but not others.
I wanted to make authorization and authentication less orthogonal. Usually, the issues of who exactly did something and whether they are permitted to do something don’t need to be tracked at the same time.
“Single version of the truth” is used today to speak of blockchain’s potential power as an audit trail. However, my vision for blockchain is highly colored by my original work on a single, immutable, cryptographically-supported, standardized, public, transparent audit trail cum report with mappings that can securely accumulate and then selectively unfold the detail to the right people.
So my goal in 2000 … significantly earlier than Satoshi Nakamoto blockchain, if later than Haber/Stornetta blockchain … was for standardized (syntax, semantics) transactions to be written to write-once media outside of the control of the Enterprise. Transactional detail, reports, and mappings between them would all be written there, and provide electronic confirmation that the detail agrees or reconciles to the reports. Managers, auditors, regulators and the public would all have appropriate access.
That “outside of the control of the Enterprise” meant external parties could use the data as they had rights to access it without concern that the Enterprise might attempt after-the-fact to alter the data.
Privacy and competitive advantage mean there needs to be limitations to who can see what in that transactional detail … while the right people can see whatever they should. (Limitations of blockchain efficiencies usually mean a lot of the detail has to be kept off-chain, and we don’t get the comfort that the right people can get the right information with data integrity unless the whole system is controlled.)
So I began working with the World Wide Web Consortium on establishing recommendations for Encryption around XML, which would permit selective unfolding of the data. Encryption – running content through an algorithm into code to minimize unauthorized access to the content – would take the easily-readable text and metadata of XBRL at the detail and report level and hide it from those who shouldn’t see it. It was a fun time working with people who used their math degrees for far more sophisticated work than I had mine – people for whom the statement, “That’s no problem; we’ll just serialize the octet stream and then base 64 encode it” rolls off their tongue as easily as “Did you see that ludicrous display last night?” might roll off mine. I remember the moment that phrase being spoken around 18 years ago as if it were yesterday.
While we normally think of encrypting a file/document as a whole, the goal with XML Encryption was to permit what I call selective unfolding. You could make some of the content available to anyone, some of the content available to some parties but not all, and some of the content only available to others. Perhaps everyone can see the reports; others can see most of the details, but not the identity information; others can see the identity detail. Whatever seemed appropriate.
With the goal of supply chain standards known as “Single Window”, and as an original goal of TaxXML – which became standard business reporting (SBR) - a single filing for all regulators would be sent to a single governmental entry point. All regulators would have access to basic information. Then the single source of the truth would selectively unfold to regulators – sales tax to sales tax people, motor fuels to motor fuels, payroll to payroll. Information wouldn’t be duplicated, leading to the need to compare notes, and each regulator would receive only that information appropriate to them.
As favor for XML gives way to favor for JSON or Semantic Web or even back to CSV files, the business and other practical benefits of selective unfolding of payload seems to be lost. But as interest in blockchain grows, the use of XML payload, which can selectively unfold to different stakeholders as appropriate, may rise yet again.
By the way; I’ve frequently found good people who confuse encryption with digital hashes. I’ve seen a lot of misconceptions that blockchains inherently contain a history of transactions in an encrypted, secure, agreed-upon manner. I am not aware of any public blockchain that captures details useful for management, auditors or regulators that is encrypted for protection from those who shouldn’t see it, but can be made clear to those who should.
Comments
- No comments found
Leave a comment