Standards Mapping
ENTITY mappings connect protocol/passport concepts to external standards so systems can interoperate without claiming ENTITY replaces, redefines or automatically conforms to those standards.
Relevant identity, provenance and rights standards
These standards are useful reference points for implementers evaluating ENTITY. The relationships below are conceptual mapping surfaces, not conformance claims.
| External standard | Current W3C status | Relevant ENTITY surface |
|---|---|---|
| Verifiable Credentials Data Model v2.0 | W3C Recommendation, 15 May 2025 | Signed claims, issuer/subject context, evidence-bearing passport records and verification boundaries. |
| Decentralized Identifiers (DIDs) v1.0 / DID v1.1 work | v1.0 Recommendation; v1.1 Candidate Recommendation Snapshot published 5 March 2026 | Persistent identifiers, controller/key relationships, portability and resolver boundaries. |
| PROV-O | W3C Recommendation, 30 April 2013 | Entities, activities, agents and provenance relationships; ENTITY adds explicit authority, rights and economic-state semantics outside PROV's scope. |
| ODRL Information Model 2.2 | W3C Recommendation, 15 February 2018 | Permissions, prohibitions, duties and asset-usage policies; candidate mapping surface for ENTITY RIGHT/policy expressions. |
Conceptual relationships
| ENTITY concept | Potential external mapping | Boundary to preserve |
|---|---|---|
| ENTITY identity | DID or another identifier method | An identifier/resolution result does not by itself create ENTITY authority. |
| Evidence / claim | Verifiable Credential-style signed claim | Signature validity proves attribution/integrity, not objective external truth. |
| Provenance | PROV Entity / Activity / Agent relationships | Provenance does not automatically establish ownership, permission or causal economic entitlement. |
| RIGHT / policy | ODRL Permission / Prohibition / Duty concepts | Policy mapping is not equivalent to legal enforceability or conformance without a defined profile and test evidence. |
| Global Passport | Container/profile carrying mapped identity, evidence and rights context | A mapping must not strengthen an external claim, issuer or standard into sovereign ENTITY authority. |
Current public domain mapping examples
| Domain | Mappings / reference standards |
|---|---|
| Healthcare | HL7 FHIR, DICOM |
| Finance | ISO 20022, FIX, LEI |
| Manufacturing | OPC UA, Asset Administration Shell |
| AI | NIST AI RMF, SPDX 3, CycloneDX |
| Robotics | ROS 2, Open-RMF |
| Defence/Public-Unclassified | Public data-governance and originator-control concepts |
What a real mapping record should contain
A production mapping should identify the exact ENTITY field/concept, external standard and version, external field/concept, direction of transformation, cardinality, canonicalization rules, validation behavior, unsupported cases, security assumptions, and mapping version. If the external standard changes, publish a new mapping version rather than silently changing interpretation.
Conformance boundary
A field correspondence is not a certification. Mentioning W3C VC, DID, PROV-O, ODRL, FHIR, ISO 20022 or another external standard does not mean ENTITY or a deployment is conformant to that standard. Conformance requires the applicable specification's own normative requirements and evidence. ENTITY mappings should therefore be described as architectural mappings unless a separate conformance record exists.
Independent review
Useful external work includes testing whether a mapped credential, DID controller, provenance record or rights policy can accidentally acquire stronger ENTITY authority, truth or ownership status than the source standard actually provides.