When Translation Becomes Judgment

The hidden boundary inside every cross-border transaction — and why the eIDAS 2 PID makes it visible

TL;DR: The ITL’s Vocabulary Agent handles cross-schema interoperability — but I’d been treating all of it as mechanical format conversion. Wrong. When a Finnish henkilötunnus meets a jurisdiction that identifies people by a composite of name, birthplace, and parentage, the operation crosses from translation into judgment. The agent is no longer reformatting fields; it is asserting that structurally different evidence satisfies the same functional requirement. That assertion is a new institutional fact, carrying unbounded liability, and it belongs in an ante-chamber — a restricted sub-context where raw evidence is evaluated and distilled into a sanitized credential before the main transaction ever sees it. The eIDAS 2 PID specification, with its twenty-two data elements and domestic namespaces, makes the problem concrete: twenty-seven Member States can translate between each other’s schemas all day. The moment a non-EU participant walks in, translation becomes judgment — and the architecture must reflect that. Along the way, the PID also illustrates a deeper problem: what happens when a well-engineered credential gets trapped inside a passive wallet.

I’ve been refining the Internet Trust Layer’s approach to interoperability for a while now, and I recently caught myself making a simplification that, left uncorrected, would have created a structural vulnerability in the architecture. The fix reveals something important about the nature of digital trust — and the EU’s own Person Identification Data specification provides both the perfect case study and a cautionary tale about the limits of good data modeling.

The problem starts with a question that sounds mundane: what happens when two parties in a transaction use different data formats?

The easy version of the problem

Say a Finnish company and a Swedish company want to trade. The Finn’s systems produce invoices in “Nordic Invoice Schema v3.” The Swede’s systems understand “Nordic Invoice Schema v2.” The fields map cleanly — a Finnish kaupparekisterinumero corresponds to a Swedish organisationsnummer. The date formats differ. The currency codes sit in different positions.

In the ITL, this is handled by a Vocabulary Agent — a system agent that publishes and manages schema definitions. The Vocabulary Agent can perform the conversion, reformatting v3 into v2, and sign the result. The signature attests: “I, the VA managing schema v3, certify that this v2 document faithfully represents the original v3 data.”

This is mechanical work. The institutional meaning of the data doesn’t change. A company registration number is a company registration number, regardless of which XML tag wraps it. The Vocabulary Agent is functioning as a translator — converting syntax while preserving semantics.

I had been treating all cross-schema interoperability as this kind of operation. That was the mistake.

The hard version of the problem

Consider a transaction context that requires both participants to be uniquely identifiable. Participant A comes from Finland, where every person carries a henkilötunnus — a single, state-issued identifier that is globally unique within the population. Participant B comes from a jurisdiction where no such atomic identifier exists. Instead, a person is uniquely identified by a combination of attributes: full legal name, date of birth, place of birth, and mother’s maiden name.

The context’s admission policy says: “Each participant must present proof of unique identification.”

The Finnish participant presents a single credential signed by the Finnish Population Register Centre. Done.

The other participant presents four separate credentials from four separate issuers. The question the context must now answer: does this bundle of evidence provide identification guarantees functionally equivalent to the Finnish atomic identifier?

This is where the operation crosses a boundary. The Vocabulary Agent is no longer reformatting data. It is evaluating whether structurally different evidence satisfies the same functional requirement. It is making a sufficiency claim — a new institutional fact that didn’t exist before the evaluation.

Follow the Searle formula. “This composite key (X) counts as unique identification (Y) in this transaction context (C).” The composite key is a brute fact — four data points. The status of “uniquely identified” is the institutional fact that the context requires. The Vocabulary Agent (or rather, the equivalence attestation service operating under its authority) is the entity performing the constitutive act. It is creating a new Y from a structurally unfamiliar X.

A translator reformats. An equivalence attester judges. These are categorically different operations, and they carry categorially different liabilities.

The eIDAS 2 PID: a well-designed credential in the wrong vehicle

This distinction might sound theoretical until you look at what the European Union is actually building right now. The eIDAS 2 regulation defines the Person Identification Data (PID) — the foundational identity credential inside the EU Digital Identity Wallet. The PID specification is, simultaneously, an impressive piece of data modeling and a cautionary tale about what happens when good design meets the wrong architectural assumptions.

The data model deserves respect. At the Architecture Reference Framework level, the PID defines nine high-level attributes for a natural person: Current Family Name, Current First Names, Date of Birth, Family Name at Birth, First Names at Birth, Place of Birth, Current Address, Gender, and Nationality/Citizenship. Three are mandatory (family name, given name, date of birth), six optional.

Those nine attributes decompose into twenty-two distinct data elements in the PID Rule Book, because the specification breaks composite attributes into sub-elements for selective disclosure. Date of Birth alone fans out into five: birth_date, age_over_18, age_over_NN, age_in_years, age_birth_year. Current Address fans out into seven: resident_address, resident_country, resident_state, resident_city, resident_postal_code, resident_street, resident_house_number. Place of Birth into four.

On top of the attributes sit seven metadata elements — issuance date, expiry date, issuing authority, document number, administrative number, issuing country, issuing jurisdiction.

And each Member State can define domestic namespaces for national attributes. The specification gives the example format eu.europa.ec.eudi.pid.de.1 for Germany. A Finnish domestic namespace might include the henkilötunnus. A Spanish one might include the DNI number. An Italian one might map to the codice fiscale.

The selective disclosure decomposition is the right instinct. Breaking Date of Birth into five sub-elements so a relying party can request age_over_18 without learning the actual birth date — that is genuine privacy engineering. The domestic namespace mechanism is elegant. The two encoding formats (ISO/IEC 18013-5 CBOR and SD-JWT JSON) show real attention to interoperability.

The delivery vehicle undermines it all.

The PID lives inside a wallet. A digital wallet is, architecturally, a passive container on a phone. It waits for a human to unlock it with biometrics, navigate a user interface, and tap “approve” for each credential presentation. This creates a cascade of structural problems that the data model, however well-designed, cannot fix.

The static snapshot problem. A PID is issued at a point in time. The specification itself acknowledges that age_over_18 changes value on the holder’s birthday, but does not require the PID Provider to reissue the credential when that happens. So the credential can be factually wrong — asserting age_over_18: false for a person who turned eighteen last Tuesday — until the provider gets around to updating it. The revocation mechanism? The PID Rule Book says, in a footnote that should concern anyone building on this specification: “PID revocation will be further detailed in a future version of ARF.” A credential without a revocation mechanism is a credential that cannot be trusted at machine speed.

The human bottleneck. Selective disclosure is technically possible, but operationally it is human-driven. There is no policy engine inside the wallet deciding which of the twenty-two elements to release based on the context of the request. The human taps “approve” on their phone, and the app-level UX determines what gets shared. This is the territory of dark patterns and cognitive overload. The person who carefully designed five sub-elements for Date of Birth assumed a rational, informed user would select precisely the right one. Anyone who has watched a real human interact with a permission dialog knows the outcome: “Accept All” and move on. The selective disclosure capability is technically present and practically decorative.

The corporate void. The PID is defined for natural persons. The Legal Person Identification Data (LPID) for corporations is barely sketched in the current specification. A multinational corporation cannot hold a wallet. A supply chain running at millisecond speed cannot wait for a CFO to perform a FaceID scan to approve each credential presentation. The entire PID architecture assumes a human in the loop — and the economy increasingly has no human in the loop.

The machine-speed problem. A CNC lathe that detects a worn bearing and needs to order a replacement part from a verified vendor cannot pull out a phone. An IoT sensor reporting environmental data to a regulatory observer cannot authenticate via biometrics. The PID has no answer for machine-to-machine identity because the wallet metaphor structurally excludes it. You cannot give a machine a passive container and expect it to participate as a sovereign peer in the economy.

What the eIDAS 2 team built is a sophisticated credential schema trapped inside a skeuomorphic delivery mechanism. The twenty-two data elements are sound. The wallet they live in is a leather pocket digitized — a “dumb bucket” that requires a human driver, at human speed, with human cognitive limitations. The data model is ready for the autonomous economy. The architecture is ready for 2015.

Three scenarios that expose the full spectrum

With this context established, the PID creates three distinct interoperability scenarios that fall along the translation-versus-judgment spectrum — and in each case, the wallet’s limitations compound the problem.

Scenario 1: Two EU Member States, same EU-wide namespace. A Finnish PID and a German PID both contain family_name, given_name, birth_date in the identical EU-wide namespace eu.europa.ec.eudi.pid.1. The data elements are identical. No translation is needed — the schemas match by design. The wallet-to-wallet presentation works here, in principle, though the human bottleneck still applies: both parties must unlock their phones and manually approve the presentation.

Scenario 2: Two EU Member States, different domestic extensions. The Finnish PID carries a domestic attribute henkilötunnus in namespace eu.europa.ec.eudi.pid.fi.1. The German PID carries Personalausweisnummer in namespace eu.europa.ec.eudi.pid.de.1. A transaction context requires “national identifier.” The Vocabulary Agent maps the Finnish domestic element to the German domestic element. The institutional meaning is the same — both are state-issued, unique, per-person identifiers. The format differs. This is Tier 1 translation. Mechanical. Bounded liability.

But notice what’s already strained: the wallet has no mechanism to invoke a Vocabulary Agent. The translation must happen outside the wallet, mediated by the relying party or an intermediary system. The wallet presents raw credentials; someone else has to translate them. The “digital leather pocket” metaphor offers no surface for attaching translation services.

Scenario 3: An EU Member State and a non-EU jurisdiction. The Finnish participant presents a PID with twenty-two well-defined data elements issued by a government-authorized PID Provider, cryptographically bound to a wallet instance, carrying metadata that includes issuing authority and validity status. The non-EU participant presents... what, exactly?

Perhaps a combination of a passport scan, a utility bill, and a notarized affidavit. Perhaps a credential from a national identity scheme that the EU has never evaluated. Perhaps a composite of attributes that partially overlap with the PID schema but use entirely different semantics — their “date of birth” field might include a birth certificate reference number, their “address” might be a GPS coordinate rather than a structured postal address.

The question is no longer “how do we reformat field A into field B?” The question is: “Does this evidence, taken as a whole, provide identification assurance equivalent to a PID issued under the eIDAS trust framework?”

That is a judgment. A big one. And the wallet architecture has no mechanism for making it, delegating it, or even expressing the question.

Where does this judgment belong?

The ITL provides a specific architectural element for exactly this class of problem. To understand why it matters, I need to explain a concept that is central to how the ITL handles privacy in complex transactions: the ante-chamber.

Think about how a high-security building works. You don’t walk from the street directly into the boardroom. You pass through a security checkpoint first — a contained space where your credentials are examined. The security guard inspects your ID, checks it against the access list, and if everything is in order, hands you a visitor badge. You enter the boardroom carrying the badge, which proves you’ve been cleared. The people in the boardroom see the badge. They never see the raw contents of your ID.

The ante-chamber in the ITL works on exactly this principle.

A Context Agent — the “digital meeting room” where a transaction executes — can be composed of multiple temporal chambers. The ante-chamber is a restricted, two-party sub-context that runs before the main context admits the participant. Its purpose is to evaluate raw, sensitive evidence and distill it into a clean, sanitized credential that the main context can consume.

The participants in the ante-chamber are limited: just the subject (the entity being evaluated) and the evaluator (the entity performing the assessment). The subject presents raw evidence. The evaluator checks it against the admission criteria defined by the main context. If the evidence satisfies the criteria, the evaluator issues a Verifiable Credential — a signed attestation of the result, stripped of the underlying evidence. The subject then presents this sanitized VC to the main context.

The ante-chamber dissolves once it has done its work. The raw evidence never enters the main context. The main context only sees the output: a signed claim that says “this party meets the requirement.”

Two things to notice about this architecture. First, no human needs to be in the loop. The subject’s Person Agent — an active software representative running 24/7, holding a policy mandate — presents evidence to the evaluator’s agent autonomously. Second, the ante-chamber has its own Finite State Machine encoding the admission policy. Different transaction types can reference different FSMs for the same category of equivalence attestation. A retail payment might accept a weaker standard. A securities settlement might demand biometric verification on top. The policy is expressed as architecture, not buried in app-level UX where a human taps “Accept All.”

Now return to Scenario 3. The non-EU participant’s Person Agent enters an ante-chamber with a specialized equivalence attester. The agent presents identification evidence — credentials from the participant’s jurisdiction, whatever their national scheme provides. The equivalence attester evaluates this bundle against the specific assurance standard required by the main transaction context. If sufficient, the attester issues a sanitized VC: “Party X presents identification evidence equivalent to eIDAS PID Level of Assurance High.”

The main context consumes this VC. The counterparty, the banks, the regulatory observers — none of them see the raw evidence. They see a signed equivalence attestation from a trusted evaluator. No wallet was unlocked. No human tapped “approve.” No passport scan leaked into a transaction context where it doesn’t belong.

Why the ante-chamber is mandatory — not optional

Three things go wrong when you try to handle Scenario 3 as inline translation inside the main context.

Privacy leaks. A non-EU composite identification bundle almost certainly contains more personal data than a structured PID. Passport scans include photographs, machine-readable zones, issuing authority details. Utility bills contain financial information. If this evidence is evaluated inside the main transaction context, every participant potentially gets exposed to data they have no business seeing. The PID specification was designed with selective disclosure in mind — the entire point of breaking Date of Birth into five sub-elements is so that a relying party can request age_over_18 without learning the actual birth date. Running a raw passport scan through the main context destroys this principle entirely.

Liability collapses. A Tier 1 translator bears liability for the accuracy of a format conversion — mapping eu.europa.ec.eudi.pid.fi.1 to eu.europa.ec.eudi.pid.de.1. The risk is bounded and mechanical. An equivalence attester in Scenario 3 bears liability for the judgment that a non-EU evidence bundle provides assurance equivalent to the eIDAS trust framework. If that judgment is wrong — if the non-EU identity turns out to be fraudulent, or the national scheme had a systemic weakness — the attester has created a false equivalence with cascading legal consequences. Collapsing both operations into a single “translation” service means the translator inherits a risk profile it was never designed to carry.

Policy becomes invisible. The equivalence standard varies by context. The PID specification defines three Levels of Assurance: Low, Substantial, and High. A low-value retail transaction might accept equivalence to LoA Substantial. A cross-border securities settlement might demand equivalence to LoA High with additional biometric verification. If equivalence evaluation is treated as inline translation, there is no architectural surface where this policy variation can live. The ante-chamber’s FSM encodes it explicitly. The main context specifies which assurance level it requires; the ante-chamber enforces it.

The two-tier framework

The fix is to split the Vocabulary Agent’s interoperability function into two explicit tiers.

Tier 1 — Schema Translation. Mechanical format conversion between semantically equivalent schemas. Finnish PID domestic namespace to German PID domestic namespace. Invoice v3 to Invoice v2. The data structures differ, the institutional meaning is identical.

Tier 1 operates inline within the main context. The Vocabulary Agent reformats and signs. The liability is bounded: “I certify this mapping is faithful.” Low risk. High throughput. No ante-chamber needed.

Tier 2 — Equivalence Attestation. Evaluative judgment that structurally different evidence satisfies the same functional requirement. Non-EU identification evidence evaluated against eIDAS PID assurance levels. Community-based identity attestation evaluated against state-issued atomic identifier requirements.

Tier 2 operates in an ante-chamber. The subject’s agent presents raw evidence. The equivalence attester evaluates sufficiency against the specific standard required by the main context. If sufficient, the attester issues a sanitized VC. The main context consumes only the result. The raw evidence stays contained. The liability is explicit, separable, and traceable.

Both tiers may be provided by the same Vocabulary Agent, or the attestation function may be delegated to a specialized agent. The architecture supports both configurations. The key constraint is structural: equivalence attestation always runs in an ante-chamber.

The grey zone — and a practical test

The boundary between Tier 1 and Tier 2 is a spectrum.

At one end: converting resident_postal_code between two Member States’ domestic formats. Purely mechanical. Obviously Tier 1.

At the other end: evaluating whether a traditional community vouching system provides identification guarantees equivalent to an eIDAS PID at Level of Assurance High. Obviously Tier 2.

In between: a wide grey zone. Is mapping between two Member States’ domestic PID extensions that define “address” differently — one using structured fields, another using a single free-text field — a translation or a judgment? If Schema A breaks the address into seven sub-elements (as the EU-wide PID does) and Schema B provides a single concatenated string, the VA must determine whether the parsed components of the string reliably map to the structured fields. That is a judgment call about data quality.

The practical test is liability. Ask: if this mapping turns out to be wrong, who bears the cost, and how large could that cost be? If the answer is “the VA, and the cost is bounded by a data formatting error,” it’s Tier 1. If the answer is “the VA, and the cost could cascade into a false identity match or a compliance failure,” it’s Tier 2 — and the evaluation belongs in an ante-chamber with its own audit trail and dispute resolution grammar.

A market for equivalence attestation

The two-tier split creates a natural economic structure that mirrors how professional services work in the physical world.

A Finnish bank interacting with a German counterparty probably doesn’t need a third-party attester. Both parties carry PIDs issued under the same EU-wide schema, and any domestic extensions map cleanly at Tier 1.

A Finnish bank interacting with a counterparty from a non-EU jurisdiction — one whose national identity scheme has never been evaluated against eIDAS assurance levels — faces a different problem entirely. Neither bank’s Vocabulary Agent has the domain expertise to evaluate whether that jurisdiction’s evidence provides equivalent guarantees.

The solution: both parties agree to invite a specialized third-party equivalence attester into the ante-chamber. This attester might be licensed by the Grammar Agent governing the transaction type, or certified by a regulatory body, or simply chosen based on market reputation and jurisdictional expertise. The attester’s track record, liability framework, and certification status become selection criteria — exactly as you’d choose an auditor or a legal translator in the physical world.

This is the “Market for Logic” applied to the interoperability problem. Equivalence attestation services compete on accuracy, speed, liability coverage, and jurisdictional breadth. The market evolves faster than any standards committee could. And unlike the eIDAS mutual recognition agreements — which require years of political negotiation between governments — the market can price and provision equivalence attestation for any jurisdiction, at any assurance level, on demand.

What the PID teaches us

The eIDAS 2 PID is worth studying precisely because it gets the hard part right and the obvious part wrong.

The hard part — decomposing identity into selectively disclosable sub-elements, defining domestic extension namespaces, specifying two encoding formats for different interoperability modes — is genuinely well-engineered. This is careful, considered credential design, and anyone building identity infrastructure should learn from it.

The obvious part — the delivery mechanism — is where the specification surrenders to the assumptions of 2014. A wallet. A passive container. A human in the loop. A static credential snapshot that the specification itself admits may go stale, backed by a revocation mechanism that is deferred to “a future version.”

The ITL argument has always been that the credential schema and the delivery architecture are inseparable. You can design twenty-two exquisitely granular data elements, but if the only way to present them is via a human tapping a phone screen, you have built a race car and chained it to a horse. The selective disclosure is technically possible and practically irrelevant, because the bottleneck is the human, and the human will always take the path of least friction — which means sharing everything or sharing nothing.

An active agent, by contrast, makes the twenty-two elements operational. The agent holds a policy mandate: “In retail contexts, release only age_over_18. In financial contexts, release family_name, given_name, birth_date, and the domestic henkilötunnus. Never release resident_address unless the counterparty presents a regulatory credential.” The agent enforces this policy at machine speed, without dark patterns, without cognitive overload, without the human even knowing a request was made and handled. The twenty-two data elements finally fulfill their design intent — because the delivery mechanism matches the data model’s ambition.

The eIDAS 2 PID specification, with its twenty-two data elements, its domestic namespaces, and its conspicuous silence on both non-EU equivalence and machine-to-machine identity, makes two problems concrete at once. The interoperability problem: twenty-seven Member States can translate between each other’s domestic extensions at Tier 1 all day long, but the moment the twenty-eighth participant walks in from outside the EU trust perimeter, translation becomes judgment. And the agency problem: a credential designed for selective disclosure loses its purpose when delivered through a passive container that has no capacity to select.

Both problems have the same root cause. The eIDAS 2 architects understood the data. They didn’t redesign the vehicle.

The fix for both is the same: active agents, operating within contexts, governed by policy-as-code. The ante-chamber handles the judgment. The Person Agent handles the delivery. The twenty-two data elements get the architecture they deserve.