Sphereon
insight
The semantic attribute model
A data attribute has a name. A semantic attribute has meaning: its purpose, legal basis, permitted issuers, disclosure constraints, retention rules, and the policy consequences that follow when it is verified. That distinction is the difference between carrying data and governing it.
Most organisations have many definitions of the same attribute, distributed across systems that were never designed to share them. HR has one interpretation of a valid professional qualification. The procurement platform has another. The access control system has a third. Each is locally consistent but globally incoherent.
That is not a data quality problem. It is a governance architecture problem. And it cannot be solved by adding more channels, including wallets, on top of a model that was never made authoritative in the first place.
A field name is not a definition.
Take “date of birth” as the simplest possible example. Every system that holds it knows the format: some standard date format.
But very few have documented: what is the legal basis for holding it, who may request it and under what conditions, how long it may be retained, what happens when the retention period expires, and whether it may be disclosed selectively rather than in full. Those are not technical questions. They are governance questions, and they need answers before the credential is issued, not after it is verified.
The same gap exists for every significant attribute: employee role, professional qualification, supplier accreditation status, machine authorisation, mandate, or health credential. The field name describes the data. The semantic definition governs it. Organisations routinely have the former and lack the latter.
What a semantic attribute definition contains.
A complete attribute definition covers eight elements. Together they turn a field name into a governed data object that every channel can reference, enforce, and audit consistently.
| Element | What it defines | Why it matters |
|---|---|---|
| Attribute type | What the data element is and how it fits within a taxonomy of related attributes. | Ensures consistent interpretation across systems and channels. |
| Legal basis | The lawful ground for processing under applicable regulation, such as GDPR Art. 6 or eIDAS 2.0. | Required to demonstrate lawful processing; determines what consent or agreement applies. |
| Issuer trust | Which issuers and trust registries are recognised as authoritative sources for this attribute. | Prevents acceptance of credentials from unrecognised or revoked sources. |
| Sensitivity | The classification level of the attribute and any handling restrictions that apply. | Drives encryption, access control, and retention decisions downstream. |
| Disclosure rules | Who may request the attribute, under what conditions, and whether selective disclosure applies. | Enforces minimal disclosure and supports privacy-by-design across every channel. |
| Retention | How long the attribute or its evidence may be held and what deletion obligations follow. | Ensures compliance with data minimisation and retention requirements. |
| Policy consequence | What access, permission, or action follows when the attribute is successfully verified. | Connects the verification event to a governed outcome rather than leaving it to each channel to decide. |
| Audit obligation | What evidence of use must be retained, in what form, and for how long. | Supports demonstrable compliance under NIS2, eIDAS 2.0, and sector-specific frameworks. |
One definition. Every channel.
When a semantic attribute definition is authoritative, every channel that touches that attribute operates from the same foundation. The wallet flow requests exactly the fields the definition permits. The portal form labels and validates the field consistently. The API enforces the same disclosure rules. The retention process applies the same expiry logic. The audit trail records the same evidence regardless of where the interaction happened.
This is what governance consistency means in practice. Not identical user interfaces. Not a single system. One definition of what the data is, what it means, and what may happen when it is used. Applied everywhere.
The alternative is what most organisations currently have: each channel encoding its own interpretation, each team making its own assumptions, and no single place where the question “what does this attribute mean and how must it be governed” has a definitive answer. That is not a legacy problem to be tolerated. It is an active governance risk that compounds with every new channel, integration, and regulatory obligation added to the organisation.
Why this is a governance necessity, not a design preference.
Under GDPR, every processing activity requires a documented legal basis. Under NIS2, organisations must demonstrate that technical and organisational measures are appropriate and consistently applied. Under eIDAS 2.0, relying parties accepting EUDI Wallet credentials must operate within defined trust frameworks with auditable verification practices. None of these requirements are satisfied by a well-designed wallet flow alone. They require a model that applies consistently across every channel where personal or organisational data is processed.
An organisation that cannot point to one authoritative definition of how each data attribute is governed cannot demonstrate that its measures are consistent. It can describe what its systems were intended to do. It cannot prove what they actually did, across which channels, under which version of policy, and with what result. That gap is precisely what regulators and auditors look for.
Under NIS2, management bears direct liability for failure to implement adequate risk measures. Board members and senior executives can be held personally accountable.
The semantic attribute model is the technical foundation that makes consistent governance provable. Without it, compliance is asserted. With it, compliance can be demonstrated.
Where Sphereon fits.
Sphereon’s EDK includes semantic attribute modeling as a core capability. Attribute definitions are created once and referenced by every channel: credential issuers, verifiers, policy engines, and audit systems all operate from the same authoritative model. A change to an attribute definition, whether a new legal basis, a revised retention period, or an updated trust registry, propagates to every channel that uses it without requiring updates to each integration separately.
IDK gives development teams the open-source building blocks to work with verifiable credential standards and implement attribute-aware credential flows. EDK gives enterprises the production-grade runtime to define, enforce, and audit semantic attributes across channels.
VDX gives organisations the operational layer to govern verifiable data exchange across parties, workflows, and trust frameworks, with the semantic model as the consistent foundation underneath.
Define the attribute. Govern every channel.
Talk to Sphereon about building a semantic attribute model that drives consistent meaning, policy, and audit across your organisation’s channels, credentials, and workflows.