Swiss e-ID vs Apple Digital ID: Two Visions of Digital Identity Compared

ComparisonIdentity FlowDigital IdentitySwiss eID

Dec 2

Written By Martina

This article started as a small comparison and turned into something a bit bigger – think, instead of an Espresso you get a Tiramisù – : an overview of two very different visions of digital identity, grouped into User View, Behind the Scenes, and Under the Hood (cheat sheet included). Switzerland’s e-ID is* built as public infrastructure with democratic oversight. Apple’s Digital ID is delivered as a polished feature inside a commercial ecosystem. Both are ambitious. Both have sharp edges. And both tell us something about how digital identity may shape everyday life in the years ahead.

Three ways to dig into this (click on it):

In story form
As cheat sheet (links to comparison included)
In more detail (you can use the cheat sheet to jump to a specific place)

And don't forgeth the last spoon

* The Swiss e-ID does not fully exist in production yet. Currently, only the public beta can be used. But since the final e-ID builds on the law approved by voters in September 2025 and the beta already reflects that design, this article mainly frames the Swiss e-ID as if it were already in use – for example, by saying “is built” instead of “will be built

Part I: The Narrative

The Swiss e-ID is a government-issued digital identity, grounded in federal law, operated by federal authorities, published through open standards, and running on an government operated trust infrastructure that is designed to support more credentials than just the e-ID. It’s careful about privacy, leans on selective disclosure, and makes big promises about not following you around the internet. At its best, together with the underlying infrastructure it’s a long-term digital foundation for an entire country, not just a feature in an app.

Apple’s Digital ID is a platform-issued digital identity. Fully Apple: tightly integrated into Apple Wallet, ridiculously smooth to use, and wrapped in Apple’s usual mix of hardware-backed security and ecosystem control, with the UX polish that makes proving your digital identity feel effortless. It’s privacy-aware too – device-retrieval, local storage, no dedicated “phone home” ping for ID checks – and for Apple-centric users, it fits into life with almost no learning curve.

The biggest differences show up in who runs the system, which rules they play by, and how protocol choices lock those decisions in over time.

Swiss e-ID – strengths & challenges

For the Swiss e-ID, the upside of treating digital identity as public infrastructure is clear: legal guarantees, democratic accountability, and a long-term commitment to serving the whole population. The flip side is complexity. The Swiss e-ID sits on an SD-JWT-VC profile – still early in actual use and not exactly settled across ecosystems (then again, what is?). Its privacy promises don’t come “for free” from the spec; they hinge on Swiss-specific design choices, especially around how credentials are issued and how status is managed, and on careful operation over time – a Swiss-specific construction that isn’t trivial to run or to reuse safely in other contexts: not just technically, but also because it is tightly coupled to the current Swiss legal, institutional and governance framework. Meanwhile, the standards world is still sorting out how SD-JWT VC fits alongside the W3C Verifiable Credentials Data Model. New tech is exciting, but new tech also means open questions and a higher bar for getting the details right.

Apple’s Digital ID – strengths & challenges

For Apple’s Digital ID, the strengths and weaknesses mirror that platform DNA. One vendor can line up hardware, software, and UX so everything feels effortless. But that also concentrates power. Apple’s Digital ID sits on top of the ISO 18013 family – the same family that allows a much more privacy-unfriendly “server retrieval” mode that critics say could enable tracking if deployed. Apple promises to avoid that mode and sticks to device-retrieval only, and not to retain “presentment information” – essentially the usage history of your ID presentations – in a way that can be tied back to you. Still, the fact that the standard bakes in a more trackable option keeps fuelling debate in the standards community. Convenience here is very real, but the privacy story depends heavily on Apple’s implementation choices and on the broader question of anchoring an ID ecosystem in one vendor’s stack and long-term decisions.

Bringing it together

So here we are: two digital ID systems, each strong in its own way, each carrying its own complexity and controversy. One built as public infrastructure; one as a platform feature. One designed with interoperability across wallets and sectors in mind; one riding on billions of Apple devices. One governed by law; one governed by platform policy.

Swiss e-ID

Full trails need verifier logs + fedpol + FOITT

Apple Digital ID

Full trails need verifier logs + Apple

Swiss e-ID and Apple Digital ID *
Aspect	Swiss e-ID	Apple Digital ID
User view
Purpose (today)	Government-issued digital ID for the Swiss ecosystem, with planned expansion for the future	Platform-issued digital ID for TSA + app/online ID checks
Launch status	Public Beta “Beta-ID”; prod ≥ Q3 2026	Live since 12 Nov 2025; gradual rollout
How to get one	Enroll on-site via passport office or remote, online via swiyu app	Add to the Apple Wallet on iPhone/Apple Watch
Required documents	Swiss ID/passport, residence/legitimation card + selfie/video	US passport (NFC) + selfie/video
Device change	Swiss e-ID must be issued again (so far)	Apple Digital ID must be added again (so far)
Behind the scenes
Ecosystem	Part of the Swiss ecosystem enabled via the government-operated public trust infra	Part of Apple Wallet ecosystem
Governance	Federal e-ID Act (BGEID); FOJ legislation + commission; FOITT infra operator; fedpol issuing authority	Apple policies + partner agreements
Issuer	fedpol (for the Confederation)	Apple (from government passport data)
Wallet	swiyu wallet (iOS/Android)	Apple Wallet (iPhone/Watch)
Devices & platforms	Runs in swiyu on iOS (iOS 16+) and Android (Android 10+); no desktop	Runs in Apple Wallet on iPhone 11+ (iOS 26.1+) and Apple Watch Series 6+ (watchOS 26.1+); no Android/desktop
Keys	Device-bound	Device-bound
Credential data storage	Encrypted on device; no central copy	Encrypted on device; no central copy
History data storage	Usage history kept locally in swiyu	Presentment history kept locally in Wallet
Application data storage	Online application: biometrics up to 5 years post-expiry; on-site: deleted	Passport/biometrics deleted after issuing; optional 90-day review data
Under the hood
Credential formats & protocols	SD-JWT-VC; OpenID4VCI/VP	ISO 18013-5/-7; Digital Credentials API (W3C)
Selective disclosure	Attribute-level presentation via SD-JWT-VC, with batch issuance	Selected data elements presentment (ISO/IEC 18013-5))
Status (revocation) mechanism	Token Status List (TSL)	Validity from signed data; no TSL list
Status check	Verifier fetches TSL; checks locally	Verifier (reader) checks Apple signature/validity
Status update	TSL is updated and made available to verifiers	Passport renewal → new Digital ID
Phone home (presentation)	Holder↔verifier; issuer not in the presentation flow; server/trust infra sees only general TSL fetches	Holder↔verifier; Apple as issuer not in the presentation flow; no server call in flow
Other server calls / telemetry	swiyu telemetry (IP, version, crashes) + coarse platform analytics	Optional device analytics
Issuer-side linkability	fedpol sees issuance/status; FOITT sees patterns only	Apple sees who added ID + status; no live use logs
Verifier-side linkability	Verifiers can pool logs; TSL helps but content linking stays	Depends on verifier logs; content linking remains
Traceability via collusion	Full trails need verifier logs + fedpol + FOITT	Full trails need verifier logs + Apple

* This "cheat sheet" reflects the state of both systems as of December 2025. It combines documented facts with expert interpretation of their architectures and operations. Details may evolve, but the core contrasts are intentionally highlighted and based on current public information.

Abbreviations used in the “cheat sheet” (and further below)

fedpol – Swiss Federal Police, issuer (on behalf of the government) of the e-ID (CH)
FOITT – Federal Office of Information Technology, Systems and Telecommunication, operator of the e-ID trust infrastructure (CH)
FOJ – Federal Office of Justice, responsible for the legislation and commissioning of the trust infrastructure (CH)
ISO/IEC 18013-5 – International standard for mobile driver’s licences (mDL) digital presentation
NFC – Near Field Communication
OID4VCI/VP – OpenID for Verifiable Credential Issuance / Presentation
SD-JWT-VC – Selective Disclosure JSON Web Token Verifiable Credential
TSA – Transportation Security Administration (US)
TSL – Token Status List

Part III: Comparison

What You See as a User

Everything that shapes the everyday experience: what the ID is for, how you get it, and what happens when you change devices

Purpose today

Swiss e-ID: Official government-issued digital identity. Intended for online authentication and authorization in Switzerland, run on the government operated trust infrastructure with an eye to many use cases (e-government, e-health, municipalities, online age-verification etc.); currently the Swiss e-ID is not usable for air travel, and cross-border use is a longer-term goal. (e-ID overview, eID.admin, Opportunities)

Apple Digital ID: A platform-issued digital identity not a government-issued one (issued by Apple based on your government issued US passport). Currently, usable in the US primarily at TSA checkpoints for domestic flights, plus early/limited support in apps and online where Digital Credentials API is inegrated. Not valid for international border crossings.(TSA - participating states, DC API)

Launch Status

Swiss e-ID: Planned launch from Q3 2026 at the earliest; Public Beta infrastructure with “Beta-ID” test credentials already available. (Public Beta)

Apple Digital ID: Launched Nov 12, 2025, rolling out in beta for use at TSA checkpoints at 250+ US airports. (Apple newsroom)

How to get one

Swiss e-ID: The enrollment for a Swiss e-ID is intended to be possible for Swiss citizens and people with a valid residence permit or a legitimation card under the Host State Act. Enrollment will be possible either on-site at a passport office or online via the swiyu wallet. (fedlex Art27, BGEID Art11-4)

Apple Digital ID: The enrollment for a Digital ID is currently exclusively possible for US citizens, based on their physical valid US passport, and only via the Apple Wallet app – no on-site enrollment possible – on an eligible iPhone or Apple Watch. (Adding your Digital ID, Adding your Digital ID - more background)

Required Documents

Swiss e-ID: Enrollment requires a valid Swiss government issued physical document such as a passport, ID card and residence permit, or a legitimation card for people working in the diplomatic and international sector plus a selfie/liveness video if applying online. Your data is then checked against federal identity registers before the e-ID is issued into your swiyu wallet. (fedlex_art14)

Note: Your personal data shown on the Swiss e-ID – such as your name and date of birth – is already stored by the government in existing identity registers and, you could say, copied into your e-ID before it is issued to you.

Apple Digital ID: Enrollment requires a valid US passport (photo page + NFC chip) plus selfie/liveness video; Apple uses this evidence (data and biometrics) to verify both you and the passport before treating the passport as valid. Once this verification succeeds, Apple issues the corresponding Digital ID credential into your Apple wallet. (Requirements to get your Digital ID)

Note: Very loosely speaking, Apple’s Digital ID behaves a bit like a “tokenized” version of your government ID inside your Apple Wallet: Apple does not issue a digital version of your passport – it verifies the authenticity of your government-issued passport and then creates an Apple Digital ID that asserts, “this user has a valid passport with these attributes”.

Device Change

Swiss e-ID: If you change phones, you need to have a new e-ID issued into your swiyu wallet, because the original e-ID is bound to the keys on your old device (check for device binding below). (Transfer to new device)

Note: The official documentation states, “in addition to the already supported hardware-binding, software-based binding will be added in the future”. (software-based binding)

Digital ID (Apple): If you change phones, your digital ID doesn’t simply appear on the new device from a backup – you need to add it again to your Apple Wallet, going through the entire device setup flow again, which creates a new device-bound key pair. (Transfer to new iPhone)

What Happens behind the Scenes

The building blocks that enable the Swiss e-ID and Apple Digital ID to function: wallets, keys, storage, governance, and the overall ecosystem setup

Ecosystem Philosophy

Swiss e-ID: The Swiss e-ID is a government-issued Digital ID that is going to be part of the e-ID ecosystem which includes a government-operated trust infrastructure, a governance structure, different roles (e.g., issuer, verifier) and components (e.g., swiyu, a government official wallet). (E-ID Ecosystem)

Note: The Swiss government both issues and signs your Swiss e-ID and operates the trust infrastructure and official wallet: a government-operated public service.

Apple Digital ID: The Apple Digital ID is a platform-issued digital ID that extends the Apple Wallet ecosystem by adding a native digital identity alongside existing features like payments and passes, all built on Apple’s device-level security and privacy model. (Wallet Ecosystem)

Note: With Apple’s Digital ID, the underlying passport is government-issued (by the US Department of State), but the digital credential itself is issued and operated by Apple.

Governance

Swiss e-ID: Regulated by the federal e-ID Act (BGEID); the technical infrastructure is operated by the federal government under public law and democratic oversight. (E-ID Act, Fedlex BGEID)

Apple Digital ID: Governed as an Apple Wallet product; rules are defined by Apple’s platform policies and partner agreements, not by a dedicated public-law framework. (IDs in Wallet)

Issuer

Swiss e-ID: The Federal Office of Police fedpol is the issuing authority for the Swiss e-ID, issuing the Swiss e-ID on behalf of the federal government. (fedpol)

Apple Digital ID: Apple issues the Apple Digital ID credential, which uses data from a US passport that is issued by the US Department of State. (Apple newsroom)

Wallet

Swiss e-ID: For now, the Swiss e-ID is planned to exclusively be issued into the government wallet (swiyu) – the official app on iOS and Android –. The law allows however future third-party wallets that meet specific requirements. (swiyu overview, swiyu on Apple Store, swiyu on Google Play)

Apple Digital ID: Issued into Apple’s own Apple Wallet on iPhone and Apple Watch; not available on non-Apple platforms. (Apple newsroom, IDs in Apple Wallet – privacy)

Supported Devices & Platforms

Swiss e-ID: The Swiss e-ID will run on smartphones with iOS 16 or later and Android 10 or later only, with no desktop or browser wallet in play. (Apple Store, Google Play Store)

Apple Digital ID: Apple’s Digital ID is tightly bound to Apple Wallet and limited to relatively recent Apple devices. To create and use a Digital ID, you currently need an iPhone 11 or later or an Apple Watch Series 6 or later running the latest iOS or watchOS; there is no Android or desktop support. (use your digital ID)

Keys

Swiss e-ID: When you add your Swiss e-ID in the swiyu wallet, your phone creates a device-bound key pair – a unique cryptographic “lock and key” that ties your e-ID only to this specific device. The private key (the one you never share) is generated and kept in the device’s security hardware (Secure Enclave on iOS; a hardware-backed secure environment, typically a Trusted Execution Environment or StrongBox, via Android Keystore on Android). (Device Binding)

Apple Digital ID: When you add your Apple Digital ID to the Apple Wallet, your iPhone or Apple Watch creates a device-bound key pair – a unique cryptographic “lock and key” that binds your Apple Digital ID only to that specific device. The private key stays inside the Secure Element, which is designed so the key cannot be copied out or exported. (Apple Wallet security details)

Credential Data Storage

Swiss e-ID: Your Swiss e-ID credential will be stored locally inside the swiyu wallet on your phone, in encrypted form. The encryption is tied to the device-bound key pair, so the credential can only be used from this device. The private key never leaves the secure hardware, and the encrypted credential is neither stored centrally nor synced to the cloud. (In-wallet storage)

Apple Digital ID: Your digital ID is stored in the Apple Wallet on your device in encrypted form. The Secure Element and Secure Enclave help protect this data and keep it isolated from the main operating system. Apple states that your ID information and presentment history are encrypted and stored only on your device, and that Apple doesn’t retain presentment information that can be tied back to you. (Digital ID added to Apple Wallet)

Usage History Storage

Swiss e-ID: Your “history of use” – a record of when (and potentially where and what) you shared with whom – is planned to be kept and updated in the swiyu app on your phone, so neither fedpol nor FOITT receive a central log of how you use your e-ID (though individual services can still keep their own logs, check for verifier side linkability below). (Usage history)

Apple Digital ID: Your presentment history – when and what you shared with whom – is encrypted, stored and updated only on your device, so Apple cannot see how you use your ID (though individual services can still keep their own logs, check for verifier side linkability below). (Presentment history)

Application Data Storage

Swiss e-ID: The law states that biometric data captured during on-site applications at the corresponding passport or migration office may not be stored in the process or forwarded to the Federal Office of Police (fedpol) and will be deleted immediately.

In contrast, for online applications, biometric data (e.g. selfie images, video) is transferred to fedpol for comparison with data on you that is already in their “ID database”. After this check the transferred biometric data is stored by fedpol for up to five years after the e-ID expires (i.e. up to 15 years in total). (what happens to my biometric data, fedlex Art27, BGEID Art11-4, Interview)

Apple Digital ID: The data read from the passport is deleted from Apple servers right after your Apple Digital ID is issued. Biometric evidence (e.g. selfie images, video) are deleted from Apple servers shortly after the Digital ID is issued or if the verification process is unsuccessful. (Apple Privacy)

Note: Apple may ask you to help improve the Wallet experience by allowing a small team of human reviewers to look at the Live Photo. If you agree, that image can be kept for up to 90 days. Apple may also temporarily store a portion of your passport data for fraud prevention. (Improving Identity Cards)

How it Works under the Hood

The mechanisms, flows, and design choices that influence how private, secure, and linkable Swiss e-ID and Apple Digital ID can be, not only for techies, but also for people who appreciate information they can use to dig further into the space

Credential Formats & Protocols

Swiss e-ID: VC format → SD-JWT VC; Protocols → OpenID4VCI (issuance) and OpenID4VP (presentation); Status → Token Status List; Device binding → KB-JWT (key-bound JWTs tied to device keys). (technology stack, device binding)

Apple Digital ID: Uses the ISO/IEC 18013-5 mdoc model for in-person flows (device retrieval, reader authentication, selective disclosure), and ISO/IEC 18013-7 Annex C with the W3C Digital Credentials API for online presentment. (WebKit DC API blog, Apple DC API dev video)

Selective Disclosure

Swiss e-ID: SD-JWT VC encodes claims so that each claim (its name and value, plus a random salt) is turned into a separate disclosure whose hash is stored in the signed credential. At presentation time, the holder can choose which disclosures to send, enabling selective disclosure. OpenID4VP profiles define how verifiers specify which attributes they need, so in principle holders can reveal only what’s required (for example, ‘over 18’) instead of their full birth data or even identity.(SD-JWT VC draft, OpenID4VP spec)

Apple Digital ID: Follows ISO 18013-5/-7 and Wallet UX where data groups can be selectively disclosed; verifiers request specific fields and users see exactly which attributes will be shared before consenting. (Apple IDs in Wallet – privacy, WebKit DC API blog)

Status (Revocation) Mechanism

Swiss e-ID: When the Swiss Confederation issues an e-ID (through fedpol as the issuing authority), it signs the credential and defines its status – for example, valid, suspended, or revoked – in a Token Status List. This list is also signed and stored in the Base Registry, operated by FOITT. Each credential contains a web address pointing to the current list (a status-list URI) and an index that points to its own entry in that list. (Base Registry)

Apple Digital ID: When Apple issues an Apple Digital ID based on your US passport (which is still issued and updated by the US Department of State), it packages selected passport data including for example the expiration date into you Digital ID credential (Digital ID for short) and signs it with its private key. As mentioned above, the signed credential is then stored locally on your device in your Apple Wallet. (Adding the Digital ID)

Status Check

Swiss e-ID: When a verifier – for example, an e-government portal, a bank, or an online shop – checks a Swiss e-ID, it uses the status-list link in the credential metadata to retrieve the current Token Status List from the Base Registry. The Swiss Confederation, represented by fedpol as the issuing authority, has signed this Token Status List with one of its issuer key. Upon retrieval, the verifier verifies the list’s signature with the issuer’s corresponding public key and then uses the index from the credential metadata to look up the entry for that credential to see whether it is still valid, suspended, or revoked. As this per-credential status check happens locally at the verifier rather than on the trust infrastructure, no information about which specific credential’s status is being checked is shared with any third party. (Swiss e‑ID revocation mechanism – token‑status list)

Note: In principle, the underlying Token Status List spec supports caching and even offline validation for a limited time, but now Swiss e-ID documentation could be found that does describe concrete caching or offline-use rules for verifiers, yet.

Apple Digital ID: When a verifier – for example, a TSA reader at an airport checkpoint – checks your Apple Digital ID, it gets your ID data directly from your iPhone or Apple Watch using the ISO/IEC 18013-5 device-retrieval flow. Apple, as the issuing authority, has digitally signed your Digital ID credential containing that data, and the TSA reader checks that signature and the embedded validity period using Apple’s public keys.

Note: Apple’s public keys live inside X.509 certificates as part of a public key infrastructure. No information could be found on how TSA systems obtain and manage these issuer certificates (for example, via on-device trust stores or backend infrastructure, and how they are updated) neither in Apple’s public documentation nor in TSA’s public documentation (beyond a high-level reference to using issuer public key certificates). (Apple Wallet security details)

Status Update

Swiss e-ID: If your Swiss e-ID changes its status along its life cycle – for example because the underlying passport, ID card, or residence permit expires or is revoked – the issuing authority (fedpol) updates the corresponding entry in the Token Status List and republishes the updated list via the Base Registry.

Note: Current public documentation does not clearly describe whether a suspended e-ID can be “reactivated” as such, or whether changes like document renewal always require issuing a new e-ID; the Token Status List itself is implemented with what could be describes as a simple valid/invalid flag. (Token Status List)

Apple Digital ID: Apple explicitly states that its Digital IDs do not automatically update when your passport is reissued – you have to delete your existing Digital ID and add a new one based on your new passport.

Note: In a device-bound, offline-verification model like this, any other changes, such as cancellation or loss of the passport, would have to be enforced by automatically updating or removing the Digital ID on your device. Apple writes that “your government issuing authority will periodically tell Apple whether your identity card is still valid”, but in the case of Digital IDs Apple itself is the issuing authority, which makes it unclear whether this mechanism applies to Apple Digital IDs and how any passport status changes are reflected in the lifecycle of a Digital ID. (Managing your Identity Card)

Phone Home (during presentation)

Swiss e-ID: When you present your e-ID, the design is holder ↔ verifier, not holder ↔ issuer: your e-ID in the swiyu wallet is presented directly from your device to the verifier using OpenID4VP, and “the government” – fedpol as the issuer and FOITT as the operator of the trust infrastructure – is not in the loop for that transaction on the identity level.

This means, there is no extra step where the swiyu app or the verifier sends a dedicated “this e-ID is being used now” back to fedpol or FOITT. The verifier still has to check whether the e-ID is valid authentic and if the issuer is legit, though. These interactions again do not involve the issuer but the registries and as such are inevitably exposing network-level metadata such as the verifier’s IP address or location etc. to the trust infrastructure operated by FOITT. From FOITT’s point of view, this interaction looks roughly like: “A service at IP X fetched or refreshed this status list at time T”. So there are limited infrastructure-level traces (the registries see that data is fetched - check telemetry data next), but no explicit “phone home” in the sense that reports the use of a specific e-ID back to “the government”. (OpenID4VP, Issuer Identification Method)

Apple Digital ID: When you present your Apple Digital ID, the design is holder ↔ verifier, not holder ↔ issuer. According to Apple’s documentation, the presentation runs on top of the ISO/IEC 18013-5 device-retrieval mode.

In other words, when you use your Apple Digital ID, the verifier needs to know whether it is valid, authentic and if the issuer is legit. These interactions happen between the verifier and your iPhone or Apple Watch. Apple’s security documentation stresses that the device-retrieval mode eliminates any need to make server calls during presentment, in contrast to the standard’s alternative server-retrieval mode, which is phone-home-capable by design.

So, while the mDL/mDoc standard itself can be deployed in a phone-home way, Apple’s Digital ID documentation states the its implementation deliberately chooses the non phone home pattern meaning, that when you use your Apple Digital ID the interaction is strictly between the verifier and you device, not between the verifier and Apple. For information on telemetry data check next. (Device Retrieval, 18013 discussion)

Other Server Calls -Telemetry Data

Swiss e-ID: For the Swiss e-ID, a layer of “background noise” that sits outside the actual presentation flow exists: telemetry from the swiyu app.

When you use the swiyu app, telemetry goes to FOITT: system data such as the IP address or app version, when you receive a credential, during a swiyu version check when you open the app, and optional app crash logs if you explicitly consent. According to the privacy statement, this data is used to operate and secure the service, fix errors, and meet legal duties. In addition, the usual aggregated app-store statistics (installs, uninstalls, crash counts, OS versions) are likely available.

This telemetry shows coarse usage patterns (for example, how many devices have the swiyu app installed on which OS versions, in what region) – similar to the telemetry many other apps on your phone generate – but not person-level trails such as “this specific person presented this specific e-ID to this specific verifier at this time”. (swiyu - privacy, swiyu - terms)

Apple Digital ID: For Apple’s passport-based Digital ID, there is also “background noise” outside the presentation itself: general platform telemetry.

Apple’s public information on iOS explains that diagnostics and usage data can be sent to Apple if you turn on device analytics. This data is described as aggregated and used to improve products, not as a per-person log of who presented which ID where. At the same time, Apple’s Digital ID privacy information says that your ID presentment history is encrypted and stored only on your device, and that Apple doesn’t retain presentment information that can be tied back to you.

In other words, Apple may see high-level information that your Wallet is being used on your device in general (for example, feature usage or crash reports, depending on your analytics settings). But this telemetry does not by itself give Apple a central, per-transaction history like “this specific person used this passport-based Digital ID at this time”. (Privacy and Security overview, shared analytics etc.)

Observability - Linkability on the Issuer side

Swiss E-ID: Fedpol, as the issuer of the Swiss e-ID, keeps the official records about who has an e-ID and if a given e-ID is valid, revoked, or suspended. Due to the technical architecture avoiding phone home fedpol does however not know for what, where or when you use your e-ID. Fedpol also does not have direct access to the trust infrastructure data, such as which registry was accessed when and from where – the legal framework separates the issuer (here, fedpol) from the operator of the technical infrastructure (FOITT).

FOITT, as the operator of the trust infrastructure, could observe patterns such as repeated calls from an IP range, how often certain networks perform status checks or fetch issuer data (from which it could get a coarse sense of how often e-IDs are used in general). But this data is not enough to simply reconstruct person-by-person trails of which e-ID was presented to which verifier, also not if FOITT should collude with fedpol.

Overall, architecture design, protocol choices (no personal data in the registries, decentralized e-ID storage on your phone) plus legal limits keep observability, and thus linkability from the issuer side, low. (Technical metadata, fedlex Absch. 2+3)

Apple Digital ID: Apple, as the issuer and operator of the Apple Digital ID and underlying infrastructure, knows which users have added a Digital ID and whether that ID is active (not expired) and correctly managed. During the enrollment process, Apple sees parts of your passport data. Due to the applied Digital ID architecture Apple does however not see any day-to-day usage logs such as “this Digital ID was used at this service at this time” or “this verifier checked this many Digital IDs in this time window”.

When you present your Digital ID, the verifier connects directly to your iPhone or Apple Watch. According to Apple’s security documentation, thereby, the ISO/IEC 18013-5 device-retrieval flow is used: the device uses keys in the Secure Element to assemble and sign the response locally, without needing to contact Apple’s servers for that transaction. This design is explicitly described as avoiding server calls during presentment in order to prevent tracking by Apple or the issuer at the moment you show your ID.

Overall, Apple can see that you have a Digital ID and that it remains usable but it does not get a picture of where and when you present your Digital ID. This means from an issuer-side point of view, observability is strongly constrained. (Server Calls, Privacy Overview)

***Linkability* *on the Verifier side***

Swiss e-ID: The real power to link specific people and events sits with verifiers and any log-sharing or collusion between them. The Swiss e-ID reduces verifier-side linkability, in its current design, by aiming for batch issuance (a finite number of e-IDs at once) and handling e-ID status changes via Token Status Lists, so colluding verifiers are less likely to see a single long-lived credential ID or a fix status-list entry they could easily reuse across services.

That’s a real improvement, but not a magic cloak. Official material is clear that plain-text attributes like name and full date of birth still allow “content-based” linking: if verifiers log “Regina Matterhorn, 01.02.1990” and later pool their logs, they can correlate those records no matter how often e-IDs or token status list entries are updated. To address this threat, the Swiss approach embeds data minimization (for example, age proofs without name or full date of birth), privacy-by-design guidance, and general data-protection law to specify how personal data can be requested, logged and pooled.

Separately from this content-based issue, and beyond what the official e-ID documentation says, cryptography experts see batch issuance as a pragmatic but incomplete privacy measure at the technical layer. It hides long-lived identifiers, but each use still leaves technical traces. In contrast, they point to anonymous-credential schemes from the BBS family (e.g. BBS+ or BBS#, while recent research suggest BBS#), which are designed to close that gap by creating a fresh, unlinkable “ticket” (a one-time code) for every interaction, so what the verifier sees does not form a stable trail – even though content-based linking remains possible if you always reveal the same plain-text data. Importantly, BBS is promising but young: today it mostly runs in software. Hardware support and standards are not here yet but likely to follow (parallel signatures could help us move toward that future without getting stuck in the meantime).

The Token Status List standard itself warns that correlation can leak through how status entries are handled. In other words, a naïve implementation can accidentally create visible patterns. For example, if a new batch of e-IDs is issued in one step so that all the status entries for that batch are added at once in a single update, an observer who compares the new list to a previous copy can see exactly which entries changed at the same time and infer that they belong to the same batch. The same problem appears on revocation: if someone loses their phone and all e-IDs from that batch are revoked together, all those status entries change state in one go. Whether those entries sit next to each other in the list or are scattered across it, a verifier who compares old and new lists can still spot the group that flipped together and learn that these entries once belonged, or now belong, to the same holder of the underlying e-ID – even if they still don’t know who that person actually is. So, to reduce that risk, the spec suggests for example padding (think of adding additional fake/fictive entries) so individual tokens or updates are harder to pick out. (How to make the Swiss e-ID unlinkable, SD-JWT draft 10 batch issuance, OpenID4VCI draft 13 batch issuance, Token Status List, BBS Cryptosuites, Cryptographers’ feedback on EU Digital Identity’s ARF, Parallel Signatures as a Bridge to BBS (Video with Manu Sporny)

Note: The content-based issue is not limited to any digital ID, but are already experienced today where in many cases scans of the passport or ID card are required online.

Apple Digital ID: For Apple’s Digital ID, the main linkability risk sits with verifiers and whatever logs and backends they operate or share.

When you present your Apple Digital ID, the verifier “talks“ directly to your iPhone or Apple Watch using the ISO/IEC 18013-5 device-retrieval flow, over an encrypted session between your device and the reader (e.g. a TSA kiosk or website, which acts as the verifier here). Apple’s documentation says that device retrieval removes the need for server calls during presentment and that both your Apple Digital ID data and presentment history are encrypted and stored only on your device. Based on this, Apple as the issuer is not meant to learn when, where, or to whom you present your Digital ID.

That’s a real improvement, but not a magic cloak either. Each verifier still sees whatever attributes it requests – (for example, “Patricia Apple”, 01.02.1990, her photo, or just “over 21”) – and can log them on its side together with timestamps, location, and other metadata. ISO/IEC 18013-5’s privacy annex recommends privacy-friendly data handling and data minimization, especially around logging, but it does not technically prevent multiple verifiers (TSA, readers, websites, shared backends) from pooling their logs and correlating repeated uses based on clear-text attributes and metadata such as timestamps or locations.

For example, if several verifiers all log “Patricia Apple”, 01.02.1990, and later share those logs, they can still link those records together, seeing what Patricia did online with her Apple Digital ID and when.

In summary, Apple’s architecture keeps issuer-side tracking out of the picture but unlinkability across verifiers largely depends on how those verifiers implement logging, retention, and data sharing – not on strong, by-design cryptographic guarantees that would make collusion technically ineffective.

Note: This content-based issue is not specific to any one digital ID scheme; we already see it today whenever scans of passports or ID cards are collected and reused in online processes. (Privacy and security overview)

Traceability - Linkability through Issuer & Verifier Collusion

Swiss e-ID: For the Swiss e-ID, each party starts with a different slice of the picture.

During an e-ID presentation, the verifier sees the rich, local view: attributes from the e-ID (for example “Regina Matterhorn, 01.02.1990”), the time, and any service-specific metadata such as IP addresses or account/session IDs it chooses to attach.

Fedpol, as issuer, does not see this data. FOITT, as infrastructure operator, sees coarse telemetry such as issuance events, app version checks, and registry traffic patterns, but no per-presentation details and no access to verifier logs.

If a verifier later shares its logs with fedpol, fedpol can use its issuance and status-list mappings to turn those logs into detailed, person-level trails for that verifier, for example, if during an age verification not name was shared. If a verifier shares its logs with FOITT, FOITT learns the same person-level trails the verifier already had, plus some infrastructure context, but FOITT alone brings little extra detail.

If only fedpol and FOITT collude, they still cannot reconstruct who used which e-ID at which verifier when, because they are missing verifier logs.

Only when verifiers, fedpol, and FOITT all share their data do full, person-level usage histories per verifier become possible; without verifier logs, issuer and infrastructure telemetry on their own are not enough to reconstruct those trails. (Public Beta Trust Infrastructure Privacy, e-ID architecture)

Apple Digital ID: For Apple’s passport-based Digital ID, each party also sees a different slice of the picture.

During the presentation at a TSA reader, the verifier sees the local view: the attributes it requested (for example, “Patricia Apple”, 01.02.1990), plus its own metadata such as timestamps, location, and internal account or session IDs.

Apple, as the issuer of the Digital ID and the infrastructure operator (Apple Wallet, iPhone etc.) is kept out of the live flow. It use ISO/IEC 18013-5 device retrieval, which avoids server calls during presentment and is explicitly described as preventing Apple from tracking when or where you present your ID, or what data was shown. Your Digital ID data and presentment history are encrypted and stored on your device, not on Apple’s servers. Apple can still receive generic device analytics if you turn them on, but these are described as aggregated, privacy-preserving usage statistics.

On its own, Apple therefore cannot reconstruct detailed trails of “this specific person used this passport-based Digital ID at this specific TSA checkpoint at this exact time” from protocol data or analytics alone; it lacks the verifier-side logs.

Full person-level histories only become possible if verifiers share their own presentation logs with Apple and those logs are correlated – just as with other strong ID checks today – rather than through any built-in “phone home” in the Digital ID system itself. (Use your Digital ID, shared analytics etc., Privacy and security overview)

The Last Spoon of Tiramisù

Thought experiment

What if Apple’s Digital ID were available in Switzerland – side by side with the Swiss e-ID – for all eligible users and ecosystem participants, from public services to banks and other commercial issuers and verifiers?

Feel free to share your thoughts in the comments or DM me directly.

Change History

Update Dec 4, 2025: Added each an image for the Swiss e-ID and the Apple Digital ID

Swiss e-IDApple Digital IDLinkabilityPhone HomeDigital IdentityPrivacy by DesignDigital TrustRevocation

Martina