How the Swiss e-ID Combines data privacy and secure identity verification

In our previous article, we examined the Swiss e-ID from a conceptual perspective, outlining its role in the digital identity ecosystem. Here, we dive into its technical implementation. Using concrete examples, we demonstrate how digital credentials are issued, stored in a wallet, and verified by businesses or authorities. We also explore the underlying standards, the roles of Issuer, Holder, and Verifier, and the data flows between these actors.

Architecture and foundations

The Swiss e-ID is built on an architecture where trusted entities issue digital credentials, users store them in a wallet, and present them to businesses or authorities on demand.

This system relies on open standards, including:

• Verifiable Credentials (VCs) (SD-JWT VC)
• Decentralized Identifiers (DIDs)
• OpenID for Verifiable Credential Issuance (OpenID4VCI)
• Verifiable Presentations (OpenID4VP).

These standards underpin key features such as Selective Disclosure and Batch Issuance, enabling targeted, privacy-preserving data sharing.

Together, they establish the foundation for interoperability, security, and data privacy, allowing digital credentials to be issued, exchanged, and verified across systems seamlessly. The following system overview illustrates how the different actors interact and the roles they assume within the e-ID ecosystem.

System overview: roles and communication

the swiss e-ID is designed as a decentralized identity system based on a clear role model. Sssuers, users, and verifying organizations each take on distinct responsibilities:

• Issuer: Issues the e-ID (e.g., a government authority)
• Holder: Individual with a wallet
• Verifier: Verifying entity (e.g., a service like fidentity)

Technically, this interaction relies on Verifiable Credentials as well as the OpenID4VCI protocol for issuance and OpenID4VP for presentation of digital credentials.

The pillars of the swiss e-ID infrastructure: The decentralized interaction between issuer, holder), verifier, and the trust registry.

After issuance by the Issuer, the digital credential is stored in the Holder’s wallet. When the person later needs to verify their identity to a company or authority, communication happens directly between the wallet and the Verifier.

The wallet sends a Verifiable Presentation, which contains only the information required for the specific use case and is cryptographically secured. Thanks to Selective Disclosure, only the necessary attributes are revealed. For example, it can prove that a person is over 18 without disclosing their exact birthdate or other personal data.

The Verifier then checks the authenticity and validity of the credential using the trust infrastructure, which provides information about trusted Issuers and their cryptographic keys. This confirms whether the credential was issued by an authorized entity and remains unaltered. No direct contact with the Issuer is required.

Crucially, the federal government is not involved in the live verification process. There is no central data matching or logged usage history. Each verification remains a bilateral exchange between Holder and Verifier.

How data is requested

Attribute queries are standardized via a verifiable presentation (VP) request. The verifier (e.g., fidentity) sends this request to the user’s wallet. With the swiyu wallet, this typically happens via a deep link or QR code, which the wallet uses to fetch the actual request.

swiyu-verify:///?client_id=did:tdw:[...]&client_id_scheme=did&request_uri=https://[...].fidentity.ch/ssi/openid4vp/[...]/client-request

Technically, the VP request defines which information is required and under what conditions it should be transmitted.

The presentation request specifies:

• Required attributes
• Technical requirements (format, signatures)
• Trust and security parameters

Typical components include an expiration timestamp, a Nonce to prevent replay attacks, and a presentation definition for the structured description of the requested data:

{
"response_type": "vp_token",
"response_mode": "direct_post",
"client_id": "did:example:fidentity",
"nonce": "…",
"response_uri": "https://[...].fidentity.ch/ssi/openid4vp/[...]/response/[...]",
"presentation_definition": {
"input_descriptors": [
{
"constraints": {
"fields": [
{ "path": ["$.given_name"], "optional": false },
{ "path": ["$.family_name"], "optional": false },
{ "path": ["$.birth_date"], "optional": false },
{ "path": ["$.issuing_country"], "optional": false },
{ "path": ["$.expiry_date"], "optional": false },
{ "path": ["$.portrait"], "optional": true }
],
"limit_disclosure": "required"
}
}
]
}
}

The wallet presents this request transparently and obtains explicit consent from the user. It then generates a matching Verifiable Presentation (VP), which is sent directly to fidentity (or other Verifiers) at the previously communicated response_uri.

VP token and cryptographic verification

This VP token contains exactly the requested attributes and is cryptographically bound to the wallet:

{
"vct": "betaid-sdjwt",
"iss": "did:example:issuer",
"iat": 1777939200,
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256"
}
},
"given_name": "Vorname",
"family_name": "Nachname",
"birth_date": "1994-08-12",
"issuing_country": "CH",
"expiry_date": "2027-08-05",
"portrait": "base64-encoded-image-data",
"status": {
"status_list": {
"uri": "https://...admin.ch/api/v1/statuslist/9647ae3b-fcac-4ff0-a5fa-49a8fd023ad2.jwt",
"idx": 1337
}
},
}

The process can be simplified as follows:

• Request (Verifier → Wallet): The Verifier (e.g., fidentity) sends a structured request for specific attributes.
• User Consent (Wallet): The user reviews the request and grants approval.
• Response / VP Token (Wallet → Verifier): The wallet creates a matching Verifiable Presentation and sends it to the Verifier.

The Verifier then checks the signatures, the integrity of the transmitted data, and its validity. No backchannel to the Issuer is required.

Validity check of the e-ID via Status Lists

In addition to cryptographic verification, a Verifier must also confirm whether a credential is still valid. The validity of an e-ID is additionally checked via a Status List. This allows revocation or status changes to be verified without disclosing personal data or creating usage profiles.

The status information is provided via a publicly accessible, signed status list:

{
"iss": "did:example:issuer",
"sub": "https://[...].admin.ch/api/v1/statuslist/9647ae3b-fcac-4ff0-a5fa-49a8fd023ad2.jwt",
"iat": 1777995398,
"status_list": {
"bits": 1,
"lst": "eNrt1dFugyAUAFB0PLBlWci-wE8h-zKzL1..."
}
}

Using the idx index from the previous VP token and the unpacked, decoded lst list, the Verifier can efficiently check whether a credential is active, revoked, or invalid. This method enables a privacy-preserving Revocation check without individual queries to the Issuer.

In practice, the Verifier combines three verification mechanisms:

• Cryptographic signatures
• Decentralized trust verification (Issuer/Trust Model)
• Status List-based revocation check

This ensures that data is authentic, unaltered, and currently valid.

Conclusion

The Swiss e-ID combines two core requirements of modern digital identity: consistent data minimization and high cryptographic security.

Selective Disclosure ensures that only absolutely necessary information is transmitted. At the same time, open standards, trust infrastructures, and cryptographic methods enable secure verification—without central dependencies or extensive data collection.

For users, this means greater control over their personal data. For Verifiers, it provides a standardized, interoperable verification process that integrates seamlessly into digital workflows.