Cryptographic Verification of Built Environment Data for Institutional Asset Use
Abstract Built environment assets depend on data generated across design, construction and operation, yet this data is often fragmented and difficult to verify over time. Institutional use of these assets requires not only data availability but also stronger guarantees of data integrity and provenance. This paper presents a verification architecture for built environment data based on cryptographic hashing, decentralized identifiers, and attestations anchored across the asset lifecycle. The approach positions verifiability as foundational infrastructure, not as a byproduct of data exchange or tokenization. We discuss how verification of asset data can reduce information asymmetry and support institutional processes such as auditing, valuation, and regulated asset use within existing frameworks.
Keywords Blockchain, data verification, data availability, decentralized identifiers, real-world assets, information asymmetry, built environment
I. INTRODUCTION
Real estate and infrastructure remain documentation-heavy asset classes, yet the data generated across the asset lifecycle is often fragmented across stakeholders, formats, and systems. Building Information Modeling (BIM), a digital representation of a building’s physical and functional characteristics used throughout design, construction, and operations, has significantly improved modeling capabilities and information management within individual project phases. However, the dominant constraint in practice is not modeling capability but reliableevidence:recordsare frequentlyincomplete,duplicated, or difficult to reconcile across organizations.
This problem becomes particularly visible during institutional processes such as refinancing, auditing, or insurance claims. For example, a commercial building undergoing refinancing may be required to produce original design specifications, inspection records, and maintenance documentation spanning multiple years. In practice, these records areoften distributedacross contractors,consultants, and facility operators, and verifying their authenticity and provenance can require extensive manual reconciliation. As a result, due diligence processes may take weeks and involve repeated validation of the same records across transactions.
The literature on BIM for existing buildings highlights persistent issues around missing or obsolete documentation, conversion effort, and uncertainty management conditions that make downstream verification slow and contested [1]. In parallel, digital twin research emphasizes continuous synchronization and decision support but often assumes the
presence of trustworthy source data and traceable updates, whicharerarelyguaranteedinmulti-partybuilt-assetworkflows [2].
This paper frames the gap as a verification problem: how to make built environment data reliably attributable, tamperevident, and portable across counterparties without a shared database or a centralized intermediary. We build on standard cryptographic primitives used for integrity commitments (e.g., hash-based structures) [3] and on emerging identity standards designed for verifiable attribution and claims exchange on the open web (Decentralized Identifiers and Verifiable Credentials) [4], [5]. While prior work has explored tokenized incentives to increase building-data availability [6] and surveyed blockchainenabled information flows in the built environment [7], the specific institutional question is under-addressed: what verification layer is sufficient to reduce rework and disputes while remaining lightweight enough to integrate with existing asset, audit, and reporting workflows [8]?
We propose a practical approach for cryptographic verification of built environment records: (i)binding documents and structured extracts to content-addressed hashes, (ii) associating those commitments with issuer identity via DIDbased attestations, and (iii) producing verifiable “evidence packages” bundled attestations with cryptographic proofs thatcanbeindependentlycheckedbythirdparties.Theintended outcome is a repeatable method that increases confidence in provenance and integrity, enabling faster diligence, clearer accountability, and lower verification cost when assets are financed, audited, insured, or tokenized (Fig. 1).
We make the following contributions: (i) A verification architecture and reference implementation model for built environment records based on content-addressable hashing, decentralized identifiers, and lifecycle attestations that enables independent validation without centralized custody or schema unification. (ii) An analysis of how cryptographic verification reduces information asymmetry and supports institutional processes including auditing, valuation, and compliance within existing regulatory frameworks. (iii) A discussion of threat boundaries, integration pathways, and limitations that positions verification as prerequisite infrastructure rather than an end-toendsolutionforbuiltenvironmentdatamanagement.Inaddition todescribingtheverificationarchitecture,weoutlineaprototype implementation demonstrating how commitments, decentralizedattribution,andledgeranchoringcanbecombined to enable independent verification of asset records across the built environment lifecycle.
Fig. 1. Conceptual relationship between a physical asset, its canonical asset record, and downstream decision and capital interfaces. Physical asset data are structuredandnormalizedintoapersistent,verifiablerepresentation,whichthen serves as trusted input for valuation, compliance, financing, and ownership transfer.
II. BACKGROUND AND RELATED WORK
Digital transformation of the built environment has been an active area of research since the mid-2000s, driven by the adoption of Building Information Modeling (BIM), asset information models, and, more recently, digital twins. Prior studies consistently identify fragmentation, version drift, and inconsistent documentation as ongoing barriers to reliable data reuse across the asset lifecycle [1], [9]. Even where digital modelsexist,recordsareoftenincomplete,difficulttoreconcile, or detached from their original authors and context, limiting their usefulness for downstream institutional processes .
Recent work explores blockchain-based approaches to coordination and transparency challenges in construction and real estate. Surveys of blockchain applications in the built environmenthighlightusecasessuchasdocumentmanagement, supply-chain traceability, and transaction automation [10], [7]. A growing subset of this literature focuses on data availability, proposing incentive mechanisms to encourage stakeholders to organize, maintain, and disclose asset data [6]. These approaches address an important economic problem: data creation and curation are costly, while the benefits are often realized later by other parties.
However, availability-oriented approaches typically assume that once data is shared, it can be trusted. For institutional use, this assumption does not hold. Auditors, lenders, insurers, and regulators requireassurances notonly that data exists, but that it has not been altered, selectively disclosed, or misattributed over time. Research in data provenance and record integrity emphasizes that trust in digital records depends on traceable lineage, attribution, and immutability guarantees, particularly in multi-party environments [11], [12].
Blockchain systems provide primitives that are directly relevant to these requirements. Cryptographic hashing enables content-addressable commitments that are tamper-evident, while append-only ledgers provide persistent ordering and timestamping [3]. Decentralized identifier (DID) frameworks and verifiable credentials extend these primitives by enabling cryptographically verifiable attribution and claims without reliance on centralized identity providers [4], [5]. These mechanismshave beenapplied in domains suchassupply-chain provenance,identitymanagement,andregulated recordkeeping, but built environment applications remain limited.
Related work in other domains has explored cryptographic approaches for verifiable document integrity and provenance. Systems such as blockchain-based document notarization frameworks and supply-chain provenance infrastructures use hashcommitmentsandappend-onlyledgerstoestablishtamperevident records across distributed participants. Similarly, integrity platforms developed for high-assurance environments, including government and cybersecurity systems, combine cryptographic hashing with immutable logging and identityboundattestationstomaintainverifiable recordsacrosscomplex data pipelines. However, these approaches typically focus on document integrity or transaction transparency rather than the lifecycleverificationofheterogeneousassetdocumentation.The built environment presents distinct challenges due to long asset lifecycles, multi-party authorship, and the need for institutional reliance on records generated across decades of operation.
III. VERIFICATION ARCHITECTURE
The proposed architecture implements cryptographic verification as a lightweight infrastructure layer for heterogeneous built environment data without centralized data custody or unifiedschemas. Rather than replacingexistingasset informationsystems, itprovidesdurable,independently verified references to records across the asset lifecycle. The architecture is composed of three core elements: content-addressable data commitments, decentralized attribution, and lifecycle attestations. Rather than proposing new blockchain protocols, the architecture combines established cryptographic primitives into a verification infrastructure tailored to the institutional workflows of built environment assets.
A. Content-Addressable Data Commitments
The architecture uses cryptographic hashing to create tamper-evident commitments to asset data. Documents, structured data extracts, or model derivatives are hashed to produce fixed-length identifiers that uniquely represent the content at that time [3]. We use SHA-256 for hash generation, providing 256-bit identifiers that are collision-resistant under current computational assumptions. These hashes may be generated for entire files or for normalized subsets, depending on the granularity required. Data must be canonicalized (for example, normalized exports with deterministic metadata handling) to avoid false mismatches caused by non-substantive file rewrites.
By anchoring hashes rather than raw data, the architecture avoids centralized storage and minimizes disclosure while preserving verifiability. Any party with the original data can independentlyrecomputethehashandverifyitsintegrityagainst the reference. Hash commitments may be recorded on a blockchain or other append-only ledger for ordering and timestamping guarantees, but the data remains off-chain. This approach aligns with established practices in contentaddressable storage and tamper-evident logging systems [13].
B. Decentralized Attribution and Identity
Verification of data integrity alone is insufficient for institutional use; attribution is equally critical. The architecture associates data commitments with decentralized identifiers (DIDs) that represent the organizations, professionals, or systems responsible for generating or attesting to records. In
built-asset workflows, issuers commonly include the architect of record, commissioning agent, inspector, energy assessor, owner’s rep, and facility operator, each attesting within their professional scope. DIDs provide globally resolvable identifiers that are cryptographically bound to public keys without reliance on centralized identity providers [4]. Implementations may use did:web for web-based identity anchoring, did:eth for Ethereum-based systems, or other DID methods depending on organizational requirements and existing infrastructure.
Using DID-based authentication, licensed professionals (e.g., architects, engineers, inspectors) can sign statements asserting authorship, responsibility, or review of data commitments. These signed statements form verifiable credentials or attestations that can be independently validated bythirdpartiesthroughstandardcryptographicverification(see Fig. 2) [5]. This enables durable attribution even as records are transferred across organizational boundaries or revisited long after their creation.
C. Lifecycle Attestations
Built environment assets evolve continuously, generating new data at each lifecycle stage. The architecture models this evolution through lifecycle attestations that reference prior commitments and introduce new ones. For example, a construction-phase inspection report may attest to a designphase model, while an operational audit may attest to both construction records and maintenance logs.
Each attestation links the relevant data commitments and identifiers, creating a verifiable chain of evidence over time. Becauseattestationsreferencecontent-addressablehashesrather than mutable files, the chain remains stable even when data is stored, migrated, or reformatted. This structure supports selective disclosure, allowing institutions to verify specific claims without requiring access to all underlying records [14]
An attestation consists of four core elements: (i) a content hash referencing the data being attested, (ii) the issuer’s DID, (iii) a timestamp, and (iv) a cryptographic signature binding these elements. For example, a construction inspection attestation might reference the hash of an inspection report, identify the licensed building inspector via DID, timestamp the attestation at the moment of approval, and include the inspector’s digital signature. This structure follows the W3C Verifiable Credentials data model, enabling standardized verification procedures.
Consider a commercial office building undergoing refinancing. The lender requires verification of original design specifications, as-built documentation, and maintenance records. Using the proposed architecture, the building owner provides attestations anchored across the lifecycle: the architect’s signedcommitmenttotheBIM model (Hash₁,2020), the inspector’s signed verification of as-built conditions referencing Hash₁ (Hash₂, 2021), and the facility manager’s signed maintenance logs referencing both prior commitments (Hash₃₋ₙ, 2021-2025). The lender retrieves these attestations from the blockchain and executes the verification workflow (Fig. 2) for each, confirming an unbroken chain of custody without requiring trust in the building owner. This reduces due
2. Third-party verification workflow. Independent verifiers confirm data integrity and attribution without requiring trust in intermediariesby following a four-step cryptographic verification process.
diligence from weeks to days, and narrows the information asymmetry between borrower and lender that would otherwise lead to conservative discounting or adverse selection.
Third-party verification proceeds in four steps: (1) retrieve theattestationandreferenceddata,(2)recomputethehashofthe data and verify it matches the attested hash, (3) resolve the issuer’s DID to obtain their public key, and (4) verify the cryptographic signature using the public key (Fig. 2). If all checks pass, the verifier can confirm that the specific data existedattheattestedtimeandwassignedbytheclaimedissuer.
D. Trust Model and Threat Boundaries
The architecture is designed to reduce, not eliminate, trust assumptions. It does not guarantee correctness of data at the point of creation, nor does it prevent intentional misrepresentation by authorized actors. Instead, it provides verifiable evidence of what data existed, who attested to it, and when. This shifts disputes from questions of authenticity to questions of responsibility and process.
The architecture addresses post-hoc record alteration, ambiguous provenance, and selective disclosure. It does not prevent collusion among authorized parties, key compromise, or inaccurate data capture.Theselimitationsare consistentwith other provenance and record-integrity systems and are discussed further in Section V [12].
E. Implementation Considerations
The architecture is blockchain-agnostic and can be implemented on any ledger providing append-only ordering and public verifiability. Practical deployment involves three key trade-offs: (i) Consensus mechanism: For institutional use, proof-of-stake or consortium-based consensus may be preferred over proof-of-work due to energy considerations and deterministic finality. (ii) Network type: Public blockchains (e.g., Ethereum, Polygon) offer stronger censorship resistance and broader accessibility, while permissioned networks (e.g., Hyperledger Fabric) may better align with existing governance structures and compliance requirements. (iii) Transaction cost: Layer-2 scaling solutions or batched commitments can reduce per-attestation costs for high-volume applications, making the approach economically viable across different asset scales and transaction frequencies.
Fig. 3. Lifecycle attestation chain for a built environment asset. Each phase generates attestations that reference prior commitments, creating a verifiable chain of evidence. Because attestations reference content-addressable hashes rather than mutable files, the chain remains stable even when underlying data is stored, migrated, or reformatted.
Data Storage and Retrieval: While attestation metadata is recorded on-chain, the underlying asset data remains off-chain to minimize storage costs and preserve confidentiality. Implementations may use content-addressed storage systems such as IPFS for decentralized hosting, or traditional cloud storage with hash references. The architecture supports hybrid approaches where sensitive data remains in private storage while non-sensitive metadata enables discovery and verification.
Scalability: For large-scale deployments involving thousands of buildings or frequent updates, batching strategies can reduce transaction costs. Multiple attestations can be aggregated into a Merkle tree, with only the root hash anchored on-chain. Individual attestations can then be verified using Merkle proofs without requiring separate blockchain transactions for each record.
Privacy and Selective Disclosure: The architecture enables graduated disclosure where verifiers can confirm specific properties (e.g., "this building has a valid energy certificate") without accessing the full underlying data. This is achieved through the separation of attestation metadata (on-chain, public) from detailed records (off-chain, access- controlled). Zero-knowledge proofs could further enhance privacy in future implementations.
Interoperability: The use of W3C-standard DIDs and Verifiable Credentials enables interoperability across different blockchain implementations and existing identity systems. Organizations can maintain their current identity infrastructure while participating in the verification ecosystem through DID resolvers that bridge legacy and decentralized systems.
IV. SYSTEMAND THREAT MODEL
Toclarifythesecurityguaranteesprovidedbytheproposed verification architecture, we describe the system participants, adversarial assumptions, and security objectives relevant to verification of built environment records across the asset lifecycle.
Thesysteminvolvesfourprincipalroles:assetownerswho maintain and disclose records; professional issuers (architects, engineers, inspectors, commissioning agents) who produce
authoritative documentation within their professional scope; facility operators who generate operationalrecords during asset use; and institutional verifiers (lenders, auditors, insurers, regulators) who must assess the authenticity and completeness of records during due diligence or compliance review.
The architecture assumes that adversaries may attempt to manipulate or misrepresent asset records. Several threat scenarios are particularly relevant in documentation-intensive assetclassessuchasrealestateandinfrastructure.First,records may be modified after theiroriginal creation in order toconceal defects or alter the historical record of an asset. Second, asset owners or intermediaries may selectively disclose documentation while withholding records that could negatively affect valuation or compliance assessments. Third, participants may dispute authorship of previously issued records or claim that documentation has been altered by another party. Finally, a malicious actor could substitute altered files while attempting to preserve the appearance of authenticity during a transaction or audit process.
The proposed architecture addresses these risks by establishing several security objectives for built environment recordverification.Thefirstobjectiveisdataintegrity,ensuring that once a record has been committed through a cryptographic hash, any modification becomes detectable through recomputation of the hash value.
The second objective is attribution, allowing records to be cryptographically linked to the identity of the issuing professional or organization through decentralized identifiers and digital signatures. The third objective is non-repudiation, meaning that an issuer cannot plausibly deny authorship of a record they have cryptographically signed. A fourth objective is temporal ordering, enabling independent verification that a record existed at a specific point in time through commitments anchored on an append-only ledger. Finally, the architecture aims to provide verifiable provenance, allowing relationships between records generated at different lifecycle stages to be reconstructed and validated by third parties.
The architecture does not guarantee that data is correct at the moment of creation. Instead, it ensures that the existence, authorship, and historical sequence of records can be independently verified. By making the evidentiary history of records transparent, disputes shift away from questions of authenticity toward questions ofresponsibility andprofessional accountability.
Fig. 4. Comparison of traditional due diligence versus cryptographic verification. The verification architecture reduces information asymmetry by enabling independent validation of data integrity and attribution without requiring trust in intermediaries.
V. PROTOTYPE IMPLEMENTATION
A prototype implementation was developed to confirm the feasibility of the architecture using existing infrastructure. Asset records were hashed using SHA-256 to generate contentaddressable commitments; issuers signed those commitments using keys bound to their DIDs; and batched commitments were anchored to a blockchain test network to provide timestamping and ordering guarantees. Verification was performed by recomputing hashes and checking signatures against the DID-resolved public keys. The prototype demonstrated that the three core mechanisms contentaddressablecommitments, decentralized attribution, and ledger anchoring can be combined using standard cryptographic libraries and distributed infrastructure without requiring new consensus mechanisms or specialized primitives.
VI. IMPLICATIONS FOR INSTITUTIONALASSET USES
Institutional reliance on built environment data is constrained less by data volume than by uncertainty regarding integrity, provenance, and responsibility. When verification is costly or ambiguous, institutions compensate through conservative assumptions, extended diligence, or repeated revalidation,increasingtransactioncostsandoperationalburden (Fig. 4) [15], [16].
The verification architecture described in Section 3 directly addresses these constraints by enabling independent validation of data integrity and attribution (Fig. 4). By binding records to cryptographic commitments and associating them with verifiable issuers, institutions can confirm that documents have notbeenalteredposthocandcanidentifythepartiesresponsible for theircreation or attestation. The verification process (Fig. 2) enables institutions to independently validate these properties without relying on the data custodian. This capability supports audit processes by reducing reliance on manual sampling and reconciliation, shifting effort toward substantive review rather than authenticity verification [16].
From a valuation and financing perspective, verifiable provenance reduces information asymmetry between asset owners and counterparties. Prior work in financial economics demonstrates that uncertainty regarding asset quality increases discounting and limits liquidity [17]. While cryptographic verification does not guarantee correctness of the data, it narrows disputes by making the history of records explicit. This can shorten diligence timelines, clarify liability boundaries, and support more consistent interpretation of asset documentation across transactions.
Regulatory and compliance functions similarly benefit from this approach. Standards governing audit evidence and record retention emphasize reliability, traceability, and resistance to tampering [18]. Cryptographically verifiable records provide an auditable trail of evidence that can be independently checked, supporting compliance assessments without imposing new reporting regimes. As illustrated in Fig. 1, the canonical asset record serves as a trusted input for these institutional processes. The architecture operates as an evidentiary layer that complements current practices without requiring changes to accounting standards or regulatory frameworks.
Finally, this verification infrastructure supports emerging applications such as asset tokenization. Where tokenized representations of real-world assets are used, the credibility of on-chain instruments ultimately depends on the trustworthiness of off-chain data [19]. By establishing verifiable links between physical assets, documentation, and digital representations, the approach supports institutional use of tokenized assets within existing governance and oversight structures.
VII. DISCUSSION AND LIMITATIONS
The verification architecture reduces uncertainty surrounding the integrity and provenance of built environment data but does not eliminate all sources of risk or disagreement. Most importantly, cryptographic verification cannot ensure the correctness or completeness of data at the point of creation. If records are inaccurate, incomplete, or misleading when first generated, subsequent verification will preserve those deficiencies rather than resolve them. This limitation is inherent to all provenance and integrity systems and reinforces the
importance of professional standards, process controls, and governance at data origination [12].
The architecture also assumes that participating actors manage cryptographic keys securely and that identifier compromise is detectable and remediable. While decentralized identifier frameworks provide mechanisms for key rotation and revocation, operational failures or collusion among authorized partiesfalloutsideourthreatmodel[20].Similarly,theapproach does not attempt to adjudicate disputes over interpretation or liability; itnarrows thescope of disagreement by making record historyexplicit,butlegalandcontractualresolutionmechanisms remain necessary.
Adoption presents additional challenges. Integrating verification into existing asset workflows requires coordination across organizations with varying technical maturity and incentives. While the architecture is designed to be modular and incrementally deployable, uptake may be uneven, particularly where verification benefits accrue downstream rather than to data originators. These coordination challenges are well documented in prior work on information infrastructure and standards adoption [21].
Three further considerations bear on deployment. First, successful adoption requires agreement on attestation schemas, DID methods, and verification procedures across stakeholders; standardization within specific domains commercial real estate, infrastructure portfolios would reduce integration costs, and industry consortia or regulatory bodies may play a coordinating role. Second, the economics of verification are asset-dependent: for high-value properties or securitized portfolios with frequent transaction and audit cycles, the cost of maintaining verified records is readily justified, whereas for smaller or infrequently traded assets it may not be. The economicthresholdatwhichverificationinfrastructurebecomes cost-effective across different asset classes warrants further study. Third, the architecture assumes ongoing availability of blockchain infrastructure and DID resolution services; the longrunsustainabilityofmaintainingverifiablerecordsacrossmultidecade asset lifecycles remains an open question, and hybrid approaches combining ledger anchoring with conventional archival systems may be necessary.
VIII.CONCLUSION
Institutional use of built environment data depends not only onavailability,butonverifiableintegrityandprovenanceacross the asset lifecycle. The verification architecture presented here based on content-addressable commitments, decentralized identifiers, and lifecycle attestations enables independentvalidationofrecordswithoutcentralizedcustodyor schema unification.
The approach supports institutional processes such as auditing, valuation, compliance, and regulated asset use within existing frameworks. The architecture is modular and incremental, allowing integration with current asset information systems rather than requiring complete replacement. Future work includes empirical evaluation across asset classes and jurisdictions, as well as further study of governance and adoption dynamics.Morebroadly, thiswork framesverification
as a prerequisite for trustworthy digital representations of realworld assets.
REFERENCES
[1] R. Volk, J. Stengel, and F. Schultmann, “Building Information Modeling (BIM) for existing buildings Literature review and future needs,” Automation in Construction, vol. 38, pp. 109–127, 2014. DOI: 10.1016/j.autcon.2013.10.023.
[2] R. Sacks et al., “Construction with digital twin information systems,” DataCentric Engineering, vol. 1,e14,2020.PublisherDOI:10.1017/dce.2020.16.
[3] R. C. Merkle, “Protocols for public key cryptosystems,” in Proc. IEEE Symposium on Security and Privacy, 1980. (Open-access record available via Semantic Scholar: https://www.semanticscholar.org/paper/Protocols-forPublic-Key-CryptosystemsMerkle/9bb0aa7c062a1ac3df0a73d1e7caa88937e9716e)
[4] W3C, “Decentralized Identifiers (DIDs) v1.0,” W3C Recommendation. https://www.w3.org/TR/did-core/
[5] W3C, “Verifiable Credentials Data Model v1.1,” W3C Recommendation. https://www.w3.org/TR/vc-data-model-1.1/
[6] S. Venugopalan and H. Aydt, “Incentivising Building Data Availability and Accessibility Using Tokenized Data Assets,” arXiv:2304.07309, 2023. https://arxiv.org/abs/2304.07309
[7] J. J. Hunhevicz and D. M. Hall, “Blockchain for a Circular Digital Built Environment,” 2023. (Open access PDF via ETH Zurich Research Collection: https://www.research-collection.ethz.ch/bitstreams/11f830fa-6298-4910a3a9-c7dcd21eb8d1/download)
[8] International Standard on Auditing (ISA) 500, “Audit Evidence,” IAASB. (Public PDF copy: https://www.icjce.es/images/pdfs/tecnica2/normativainternacional/isa500.pdf )
[9] C. Eastman, P. Teicholz, R. Sacks, and K. Liston, BIM Handbook, 3rd ed. Hoboken,NJ,USA:Wiley,2018.(Publisherpage:https://www.wiley.com/enus/BIM+Handbook%2C+3rd+Edition-p-9781119287568)
[10] M. Turk and R. Klinc, “Potentials of blockchain technology for construction management,” Procedia Engineering, vol. 196, pp. 638–645, 2017. doi: 10.1016/j.proeng.2017.08.052.
[11] Y. L. Simmhan, B. Plale, and D. Gannon, “A survey of data provenance in escience,” SIGMOD Record, vol.34,no.3,pp.31–36,2005.doi: 10.1145/1084805.1084812.
[12] L. Moreau, “The foundations for provenance on the web,” Foundations and Trends in Web Science, vol. 2,no.2–3,pp.99–241,2010.doi: 10.1561/1800000006.
[13] J. Benet, “IPFS Content addressed, versioned, P2P file system,” arXiv:1407.3561, 2014.Available:https://arxiv.org/abs/1407.3561.
[14] A. Tobin and D. Reed, “The inevitable rise of self-sovereign identity,” The Sovrin Foundation, 2017.Available:https://sovrin.org/wpcontent/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf.
[15] M.Power, The Audit Society: Rituals of Verification, OxfordUniversity Press,1997.(Publisherpage:https://global.oup.com/academic/product/theaudit-society-9780198296034)
[16] J. L. Bedard, “The discipline of audit quality,” Accounting Horizons, vol.24, no. 2,pp.171–181,2010.doi:10.2308/acch.2010.24.2.171.
[17] G. Akerlof, “The market for ‘lemons’: Quality uncertainty and the market mechanism,” Quarterly Journal of Economics, vol.84,no.3,pp.488–500, 1970. Available:https://www.jstor.org/stable/1879431
[18] ISO, “ISO 15489-1:2016Informationanddocumentation Records management,” 2016. (Overview: https://www.iso.org/standard/62542.html)
[19] P. Tasca and C. Tessone, “A taxonomy of blockchain technologies,” Ledger, vol. 4,2019.Available: https://ledger.pitt.edu/ojs/index.php/ledger/article/view/140
[20] D. Reed et al., “Decentralized identifiers: Principles and practice,” IEEE Security & Privacy, vol. 19,no.3,pp.26–35,2021.doi: 10.1109/MSEC.2021.3054015.
[21] G. C. BowkerandS. L. Star, Sorting Things Out: Classification and Its Consequences, MITPress,1999.(Publisherpage: https://mitpress.mit.edu/9780262024617/)
ACKNOWLEDGEMENTS
Thank you to Robert M. Orozco of Afirmity and Spencer X. Smith of AmpliPhi for reviewing this piece and providing suggestions. AI tools were used to improve the paper’s grammar and readability.