A door is a relying party. That is the quiet claim inside the Personal Identity Agent work that Mayrhofer et al. published from JKU Linz in 2025 (arXiv 2508.10185): decentralized identity leaves the browser tab and walks into doors, transit gates and border posts. Read it as a systems diagram and the picture rearranges itself. The site turnstile, the BIM-server login and the client’s viewer link stop being three IT tickets and become three instances of one architecture, with the same roles, the same failure modes and the same single points of failure you have not found yet.

The pressure arrives from two sides. Switzerland’s federal e-ID is scheduled to launch in December 2026. As PAZ has reported, a CHF 1.7 million budget cut removed cross-border interoperability, the federal back-up service and third-party-wallet issuance from the first release. It is a live lesson that what a system leaves out at launch is a design decision, not a detail. Meanwhile, as Biometric Update reported, AI agents are exposing the gap between identity and authority, pushing GLEIF, the FIDO Alliance and iProov to build verifiable-trust and human-approval layers. A person, a wallet, a script and an agent now ask the same gate the same question. This essay is about the architecture that answers it.

What it is: Digital identity architecture is the arrangement of roles, keys and checks that binds a claim (“I am the certified BIM coordinator on this project”) to a subject. It lets a party who has never met that subject act on the claim safely. It is not the login screen. The login screen is one enforcement point bolted on top. The architecture is the whole load path: who enrolled you, who holds the proof, who checks it, who acts on the result, and who decides which issuers count at all. Most diagrams leave out that last part.

Why it works: The mechanism is separation of roles. According to NIST’s Digital Identity Guidelines, SP 800-63 (now in its 800-63-4 revision), six roles carry the load:

• the applicant, who wants an identity
• the subscriber, who holds one
• the claimant, who is proving it right now
• the credential service provider, who proofs and enrols
• the verifier, who confirms possession of the authenticator for this transaction
• the relying party, who acts on the verifier’s assertion without ever touching the raw credential

Keep those roles in separate hands and no single operator sees everything. Collapse them and you have rebuilt the all-knowing operator the design exists to prevent.

Three pieces of engineering hold that separation up:

• Signatures that verify offline. An issuer signs a credential with a private key, and anyone holding the public key can check it without phoning home. Ed25519, the scheme Daniel J. Bernstein, Tanja Lange and colleagues published in 2011, does this with 32-byte public keys and 64-byte signatures.
• Per-request verification. This comes from zero-trust architecture as NIST SP 800-207 specified it in 2020. The decision plane (who is allowed) sits apart from the enforcement plane (what actually opens), and every request earns a fresh verdict. Merge the two and a stolen token becomes a master key.
• A governed root of trust. A list, a ledger or a registry says which issuer keys are authorised. Cryptography tells you a key is real. Governance tells you the key is allowed to speak.

Here is the trade-off, stated plainly. Decentralized designs give you unlinkability, and they also give you the job of governing the root of trust yourself. You pay that cost in committee hours and liability, not in code. Every national e-ID, the Swiss one included, is a negotiated position on that line.

Origins: The question is older than the machine. A wax seal, a signet ring, a password at a city gate: each tried to bind a claim to a body. Digital identity became its own discipline when we learned that the identifiers we had grabbed were copyable strings: passwords, email addresses, social-security numbers. A string anyone can copy proves nothing about who holds it. The first architectures were centralised. An authority owned the identifier, and closing the account erased the digital self even though the person survived. NIST’s first edition of 800-63 appeared in 2004 and gave that world its vocabulary. The engineers who have revised it since drew the floor plan most Western systems are laid out against, and almost nobody knows their names.

Then came the reframe. In 2019 Goodell and Aste at UCL made a human-rights argument: a person must be able to hold several unrelated identities, so that no single operator can assemble them into one aggregated profile. That sentence powered the decentralized-credential agenda. It runs through the Sovrin network and the W3C Verifiable Credentials and Decentralized Identifier stack from 2017 onward, and on to the wallets now being argued over across Europe.

Switzerland has its own strand of the same instinct. In 2020 the EPFL- and ETH-led DP-3T team around Carmela Troncoso designed contact tracing so the sensitive graph stayed on phones and never pooled on a server. The problem was different but the principle was the same: make aggregation impossible, not just forbidden.

At the other end of the scale sits Aadhaar, launched by India’s UIDAI in 2009 and now at near-complete population coverage. Choudhary and Kaushik (ECIS 2023) read it as an architecture of generativity, a foundation others build services on. That is exactly why its scale is both its achievement and its risk.

←TODAY: Switzerland’s federal e-ID is due in December 2026, after a CHF 1.7 million cut removed cross-border interoperability and third-party wallets from the first release.
→3012: In Zurich 3012 the site gate, the model server and the border read the same wallet, and no one types a password.
Fulcrum: The roles NIST named are a load path. Collapse them into one operator and you have built the single point of failure yourself.

In practice: Map the roles onto a Swiss site and the concept stops being abstract. Picture a hospital extension with a dozen contractors. Each subcontractor’s HR system is effectively its own credential service provider. The general contractor’s turnstile is a relying party, and so is the common data environment. The badge federation between them is where verification either happens at every entry or quietly decays into “badged in at 07:00, trusted until dusk”. The IFC model now deserves the protection you give the plant on site. Whoever opens it should be verified for each action, not trusted because they logged in that morning.

The quieter claimants are machines: a Grasshopper definition writing elements into Archicad through Graphisoft’s Python/JSON API or the PAZ Grasshopper↔Archicad Library, a survey drone uploading a point cloud, an AI agent drafting a submittal. Each acts on someone’s behalf, and each raises the question the agent-governance debate keeps coming back to: whose authority is this, and who approved it? Give scripts and agents their own scoped credentials as subscribers in their own right, instead of letting them borrow a human session.

Swiss offices already write roles and responsibilities into the BEP, with SIA 2051 as common ground for applying the BIM method. The identity layer belongs in that same execution plan, next to LOIN and the exchange schedule, not in an IT ticket nobody on the project reads.

Atelier: For an office living with AI assistants and automation scripts, the identity map is now also an authority map: every agent that writes to the model is a claimant someone has to verify. The Monday move: take one live project and list every identity that touches the model, whether person, script, agent or viewer link. For each, write down its NIST role and when it was last verified, then revoke any standing access that survives only because nobody checked it again.

Hack: Audit who your IFC file says built it, and notice what kind of evidence that is. Every IFC product can carry an IfcOwnerHistory that names an owning person-and-organisation and an owning application. IfcOpenShell, the open library Thomas Krijnen started and Dion Moult’s Bonsai builds on, reads it in five lines:

import ifcopenshell, collections
model = ifcopenshell.open('project.ifc')
hist = [p.OwnerHistory for p in model.by_type('IfcProduct') if p.OwnerHistory]
who = collections.Counter((h.OwningUser.ThePerson.FamilyName or '?', h.OwningApplication.ApplicationFullName) for h in hist)
for (user, app), n in who.most_common(): print(f'{n:6d}  {user:<20} via {app}')

Run it on a federated model and you get a ledger of authorship that was typed into settings dialogs and signed by no one. It is a claim with no verifier, which is exactly the gap a signed credential closes. Set that list beside the people who actually hold write access in your CDE. The mismatch is your first finding.

From the late 2070s, the danger I would warn you about is not broken cryptography. The failures that hurt were quiet dependencies: one identity provider behind every contractor badge, one wallet vendor behind every gate, one retiring administrator who was the only person who knew how the trust list was governed. Single points of failure stay silent until the day they don’t. Draw the real dependency graph of your project’s identities, not the architecture slide, and look for the third single point you did not know you had.

Identity is becoming a structural material of the built environment. The Linz PIA work points toward one wallet that both proves you are a certified coordinator and opens the site gate. When that happens, the architects who matter will not be the ones writing the cryptography. They will be the ones who ask at the first coordination meeting: who is allowed to open this, and how do we check it every single time? Write that question into the BEP before the first door is specified, because retrofitting trust into a building already full of doors is the most expensive detail there is.