User-Centric Mobility Access with e-ID

AI Quick Summary

Travellers in Switzerland must manage multiple apps, accounts, and cards across disconnected transport operators — there is no single portable identity that works across all of them.  We propose a user-controlled digital wallet built on Verifiable Credentials, where mobility entitlements are issued once and held by the user rather than scattered across operator silos. Zero Knowledge Proofs allow users to prove entitlement to any operator — train, bus, bike — without revealing unnecessary personal data.  A decentralised operator registry ensures credentials are only shared with verified operators, making trust bidirectional and removing any single point of control.  Problem - Identity in Swiss Mobility Is Fragmented  A person travelling across Switzerland today must maintain separate accounts, cards, and applications for every transport operator they use.  Their GA lives with SBB   PostAuto requires separate verification   PubliBike has its own login   A disability card is shown manually at each touchpoint   An employer mobility budget is managed in a separate system   There is no single portable identity that works across all operators.  Every journey requires the user to prove who they are and what they are entitled to — repeatedly, across disconnected systems that do not communicate with each other.  The natural response to this fragmentation is centralization — one platform that holds everyone's identity and manages access on their behalf.  But centralization creates its own serious problems:  Whoever runs the central platform sees every journey and every entitlement check of every user in Switzerland   Operators must hand their user verification over to a third party they may not trust   A single breach exposes the complete mobility profile of the entire population   No single company or government body is an acceptable owner to all stakeholders in a competitive ecosystem     Proposed Solution - One Wallet. User-Controlled. Works Everywhere.  We propose a user-controlled digital wallet that holds all mobility-relevant credentials in one place:  A GA   A disability card   An employer mobility budget   Any other entitlement   The user carries this wallet on their phone.  When accessing any transport service, the user presents their wallet. The operator asks one simple question:  Is this person entitled?  The operator receives a verified answer — nothing more.  This is not a new central platform.  There is no intermediary between the user and the operator. The user owns their credentials directly, and cryptographic proofs replace the need for a trusted middleman.  Three Technical Pillars  Verifiable Credentials (VCs)  W3C open standard for portable digital credentials   Issued once by a trusted authority   Held by the user   No operator owns the user's identity   Zero Knowledge Proofs (ZKP)  Cryptographic mechanism allowing a user to prove a claim is true without revealing underlying data   Operators receive only what they need — nothing more   Decentralised Operator Registry  Blockchain-based registry of trusted issuer public keys   Verifiers check it to confirm a credential was issued by a recognised authority     Achitecture - The Actors and How They Interact  The system involves four actors. Each has a clearly defined role with no overlap.  Issuer  Examples: Swiss e-ID authority, SBB, employer  Verifies the user once and issues a signed digital credential   Stores nothing about the user after issuance   The credential lives with the user, not the issuer     User / Holder  Example: The traveller  Holds all credentials in their wallet   Controls what gets shared and with whom   Generates ZKP proofs on-device   No data leaves the wallet without user action     Verifier / Operator  Examples: SBB, PostAuto, PubliBike  Asks one specific entitlement question   Receives a cryptographic proof — true or false   Does not need to store user data to verify access   Integrates via a lightweight SDK     Registry  Governed by: KOMODA and FOT  Decentralised list of verified Swiss mobility operators   Publicly readable, controlled write access   No user data stored — only operator public keys and verification status     The Decentralised Registry  When a verifier receives a credential proof from a user, they need to confirm the credential was issued by a trusted authority.  They do this by checking the decentralised registry for the issuer's public key.  If the key is present and active, the credential is trusted   If not, it is rejected   The registry stores only one thing per issuer:  Their public key   Who they are   Their verification status   No user data, journey data, or credential contents are ever stored on the registry.  It only grows when a new issuer joins the ecosystem — not with every journey or every credential issued.  Write access is controlled by KOMODA and FOT — they decide which issuers are trusted.  Read access is public — any verifier can check it freely at any time.  For the prototype, the registry will be deployed on a suitable test blockchain.  The choice of final infrastructure — public or permissioned blockchain — is a governance decision deliberately left open at this stage.  Designed to work before MODI  This identity layer does not depend on MODI legislation to function. An issuer, a user wallet, a verifier, and a decentralised registry are all that is needed — and all four can be operational today using existing technology and under current Swiss law. Operators can begin adopting the system before MODIG comes into force in 2028. When MODI does arrive, this identity layer is designed to integrate naturally as the access and entitlement layer on top of NADIM — not as a replacement but as a complement.    How It Works - The Verification Flow  A user travelling from Zurich to Zug opens their wallet and presents a proof at each transport touchpoint:  Train   Bus   Bike   At each step, the operator receives only what they need to confirm entitlement.  The proof is generated locally on the user's device from their stored credential.  The operator checks the issuer's public key against the registry to confirm it is trusted.  No personal data is exchanged   No central system is called   Verification completes in seconds and the user moves on     Implementation - Prototype Development Plan — 6 to 8 Months  The project is structured as an incremental prototype build.  Each phase produces something working that the next phase builds on.  The goal at the end is a demonstrable end-to-end flow — not a production system.      Phase  Timeline  What We Build  Milestone  Phase 1  Months 1–2  Research and concept definition. Understand current pain points, map actor interactions, and define the credential structure. No code yet — focus on design clarity for the build phase.  Agreed system design, defined credential schema, and documented actor interaction model  Phase 2  Months 2–4  Build a minimal prototype to validate the core workflow. A simulated issuer generates a signed VC, the user wallet stores it, and the verifier receives a ZKP proof and checks a test registry smart contract. End-to-end flow runs in a controlled environment with mocked operators.  Working credential issuance → ZKP proof → registry verification flow, even if rough  Phase 3  Months 4–6  Develop core features. Improve wallet UX, harden ZKP proof generation, deploy the registry smart contract to a public testnet, and support multiple credential types and operators to validate multi-operator workflows.  Stable prototype   Phase 4  Months 6–8  Testing and validation with real users. Gather feedback on wallet usability and trust perception, identify what works and what doesn’t, document open production questions, and prepare the final demonstration.  Validated prototype, user feedback report, and a clear list of open questions for the next stage      How This Connects to the Bigger Picture  MODI is solving the data layer — how operators share information with each other through NADIM.  But seamless mobility also requires a seamless identity layer — how users prove their entitlement to access the services that data layer enables.  These two layers are complementary and both necessary for MODI's vision to be fully realised.    Public-Private Integration  The identity layer is designed to work across both public transport operators and private mobility services within a single user wallet. A practical example is a journey combining SBB rail with Lime e-scooters or Mobility Carsharing for the last mile. Today these require separate accounts and separate verification. With this system, the user holds credentials from both public and private issuers in one wallet and presents a single proof at each touchpoint regardless of whether the operator is publicly or privately operated. This makes the wallet genuinely useful for the full range of mobility options a Swiss commuter uses — not just public transport.  Collaborations for Testing  To validate the prototype in realistic conditions, we aim to engage with at least one public transport operator and one private mobility service provider during the testing phase. These collaborations would focus on gathering technical and operational feedback on the credential and verification flow — keeping the partnership lightweight and achievable within the project timeline rather than requiring deep system integration.      MODI Vision  MODI vision └── NADIM data exchange between operators     └── Identity Layer how users access those services ← this proposal         └── VCs portable user credentials         └── ZKP privacy-preserving verification         └── Registry trusted issuer directory  This project is positioned as a concept and prototype contribution.  The goal is to:  Demonstrate that the identity problem is solvable with existing open standards   Provide a working reference design that KOMODA and FOT can build on     Why we are positioned to do this  This proposal is grounded in hands-on experience with blockchain technology and decentralised systems. Our technical background includes thesis-level research covering distributed ledger architectures, smart contract design, and decentralised trust mechanisms — directly relevant to the registry and verification components of this proposal. Beyond academic work, we have applied this knowledge in practical blockchain solution development, designing and building systems that use distributed ledgers for trust, access control, and data integrity in real-world contexts.  Research Partner — HSLU (Hochschule Luzern) The project is supported by a research team at HSLU comprising Stefano Gioia, Associate Research Scientist, and Prof. Dr. Widar von Arx, Head of the Competence Center Mobility at the Institute for Tourism and Mobility (ITM) and board member of Basler Verkehrsbetriebe (BVB). The HSLU team provides academic validation of the technical approach, independent evaluation of the ZKP privacy guarantees, and deep expertise in public transport and mobility management — ensuring the proposal stays grounded in the realities of the Swiss mobility ecosystem. HSLU is located in Luzern, directly on the pilot corridor. Partnership confirmed.  Advisory and Oversight Strategic guidance is provided by Dr. Hermann Sterzinger, Chairman of the Advisory Board at TrustNoteD GmbH, with over 25 years of experience working with governments, central banks, and commercial banks. He is co-founder of AUGENTIC, former COO of Veridos, former Group Senior Vice President at Giesecke+Devrient, and served as ICAO operational Board Member for the Public Key Directory from 2015 to 2019. He holds a PhD in Competition and Intellectual Property Law from TUM and lectures there, providing strategic guidance on government-sector solutions and international standards alignment.  Business development is led by Florian Leicher of TrustNoteD GmbH, with over 35 years of experience delivering secure transaction and digital infrastructure solutions to financial institutions and merchants worldwide. 

Project Idea Metadata

Project Idea Name: User-Centric Mobility Access with e-ID
Date: 5/29/2026 3:10:50 PM
Administrators:
- Deepankar Ratra

Project Idea Description

Problem - Identity in Swiss Mobility Is Fragmented

A person travelling across Switzerland today must maintain separate accounts, cards, and applications for every transport operator they use.

Their GA lives with SBB

PostAuto requires separate verification

PubliBike has its own login

A disability card is shown manually at each touchpoint

An employer mobility budget is managed in a separate system

There is no single portable identity that works across all operators.

Every journey requires the user to prove who they are and what they are entitled to — repeatedly, across disconnected systems that do not communicate with each other.

The natural response to this fragmentation is centralization — one platform that holds everyone's identity and manages access on their behalf.

But centralization creates its own serious problems:

Whoever runs the central platform sees every journey and every entitlement check of every user in Switzerland

Operators must hand their user verification over to a third party they may not trust

A single breach exposes the complete mobility profile of the entire population

No single company or government body is an acceptable owner to all stakeholders in a competitive ecosystem

Proposed Solution - One Wallet. User-Controlled. Works Everywhere.

We propose a user-controlled digital wallet that holds all mobility-relevant credentials in one place:

A GA

A disability card

An employer mobility budget

Any other entitlement

The user carries this wallet on their phone.

When accessing any transport service, the user presents their wallet. The operator asks one simple question:

Is this person entitled?

The operator receives a verified answer — nothing more.

This is not a new central platform.

There is no intermediary between the user and the operator. The user owns their credentials directly, and cryptographic proofs replace the need for a trusted middleman.

Three Technical Pillars

Verifiable Credentials (VCs)

W3C open standard for portable digital credentials

Issued once by a trusted authority

Held by the user

No operator owns the user's identity

Zero Knowledge Proofs (ZKP)

Cryptographic mechanism allowing a user to prove a claim is true without revealing underlying data

Operators receive only what they need — nothing more

Decentralised Operator Registry

Blockchain-based registry of trusted issuer public keys

Verifiers check it to confirm a credential was issued by a recognised authority

Achitecture - The Actors and How They Interact

The system involves four actors. Each has a clearly defined role with no overlap.

Issuer

Examples: Swiss e-ID authority, SBB, employer

Verifies the user once and issues a signed digital credential

Stores nothing about the user after issuance

The credential lives with the user, not the issuer

User / Holder

Example: The traveller

Holds all credentials in their wallet

Controls what gets shared and with whom

Generates ZKP proofs on-device

No data leaves the wallet without user action

Verifier / Operator

Examples: SBB, PostAuto, PubliBike

Asks one specific entitlement question

Receives a cryptographic proof — true or false

Does not need to store user data to verify access

Integrates via a lightweight SDK

Registry

Governed by: KOMODA and FOT

Decentralised list of verified Swiss mobility operators

Publicly readable, controlled write access

No user data stored — only operator public keys and verification status

The Decentralised Registry

When a verifier receives a credential proof from a user, they need to confirm the credential was issued by a trusted authority.

They do this by checking the decentralised registry for the issuer's public key.

If the key is present and active, the credential is trusted

If not, it is rejected

The registry stores only one thing per issuer:

Their public key

Who they are

Their verification status

No user data, journey data, or credential contents are ever stored on the registry.

It only grows when a new issuer joins the ecosystem — not with every journey or every credential issued.

Write access is controlled by KOMODA and FOT — they decide which issuers are trusted.

Read access is public — any verifier can check it freely at any time.

For the prototype, the registry will be deployed on a suitable test blockchain.

The choice of final infrastructure — public or permissioned blockchain — is a governance decision deliberately left open at this stage.

Designed to work before MODI

This identity layer does not depend on MODI legislation to function. An issuer, a user wallet, a verifier, and a decentralised registry are all that is needed — and all four can be operational today using existing technology and under current Swiss law. Operators can begin adopting the system before MODIG comes into force in 2028. When MODI does arrive, this identity layer is designed to integrate naturally as the access and entitlement layer on top of NADIM — not as a replacement but as a complement.

How It Works - The Verification Flow

A user travelling from Zurich to Zug opens their wallet and presents a proof at each transport touchpoint:

Train

Bike

At each step, the operator receives only what they need to confirm entitlement.

The proof is generated locally on the user's device from their stored credential.

The operator checks the issuer's public key against the registry to confirm it is trusted.

No personal data is exchanged

No central system is called

Verification completes in seconds and the user moves on

Implementation - Prototype Development Plan — 6 to 8 Months

The project is structured as an incremental prototype build.

Each phase produces something working that the next phase builds on.

The goal at the end is a demonstrable end-to-end flow — not a production system.

Phase	Timeline	What We Build	Milestone
Phase 1	Months 1–2	Research and concept definition. Understand current pain points, map actor interactions, and define the credential structure. No code yet — focus on design clarity for the build phase.	Agreed system design, defined credential schema, and documented actor interaction model
Phase 2	Months 2–4	Build a minimal prototype to validate the core workflow. A simulated issuer generates a signed VC, the user wallet stores it, and the verifier receives a ZKP proof and checks a test registry smart contract. End-to-end flow runs in a controlled environment with mocked operators.	Working credential issuance → ZKP proof → registry verification flow, even if rough
Phase 3	Months 4–6	Develop core features. Improve wallet UX, harden ZKP proof generation, deploy the registry smart contract to a public testnet, and support multiple credential types and operators to validate multi-operator workflows.	Stable prototype
Phase 4	Months 6–8	Testing and validation with real users. Gather feedback on wallet usability and trust perception, identify what works and what doesn’t, document open production questions, and prepare the final demonstration.	Validated prototype, user feedback report, and a clear list of open questions for the next stage

How This Connects to the Bigger Picture

MODI is solving the data layer — how operators share information with each other through NADIM.

But seamless mobility also requires a seamless identity layer — how users prove their entitlement to access the services that data layer enables.

These two layers are complementary and both necessary for MODI's vision to be fully realised.

Public-Private Integration

The identity layer is designed to work across both public transport operators and private mobility services within a single user wallet. A practical example is a journey combining SBB rail with Lime e-scooters or Mobility Carsharing for the last mile. Today these require separate accounts and separate verification. With this system, the user holds credentials from both public and private issuers in one wallet and presents a single proof at each touchpoint regardless of whether the operator is publicly or privately operated. This makes the wallet genuinely useful for the full range of mobility options a Swiss commuter uses — not just public transport.

Collaborations for Testing

To validate the prototype in realistic conditions, we aim to engage with at least one public transport operator and one private mobility service provider during the testing phase. These collaborations would focus on gathering technical and operational feedback on the credential and verification flow — keeping the partnership lightweight and achievable within the project timeline rather than requiring deep system integration.

MODI Vision

MODI vision
└── NADIM data exchange between operators
    └── Identity Layer how users access those services ← this proposal
        └── VCs portable user credentials
        └── ZKP privacy-preserving verification
        └── Registry trusted issuer directory

This project is positioned as a concept and prototype contribution.

The goal is to:

Demonstrate that the identity problem is solvable with existing open standards

Provide a working reference design that KOMODA and FOT can build on

Why we are positioned to do this

This proposal is grounded in hands-on experience with blockchain technology and decentralised systems. Our technical background includes thesis-level research covering distributed ledger architectures, smart contract design, and decentralised trust mechanisms — directly relevant to the registry and verification components of this proposal. Beyond academic work, we have applied this knowledge in practical blockchain solution development, designing and building systems that use distributed ledgers for trust, access control, and data integrity in real-world contexts.

Research Partner — HSLU (Hochschule Luzern) The project is supported by a research team at HSLU comprising Stefano Gioia, Associate Research Scientist, and Prof. Dr. Widar von Arx, Head of the Competence Center Mobility at the Institute for Tourism and Mobility (ITM) and board member of Basler Verkehrsbetriebe (BVB). The HSLU team provides academic validation of the technical approach, independent evaluation of the ZKP privacy guarantees, and deep expertise in public transport and mobility management — ensuring the proposal stays grounded in the realities of the Swiss mobility ecosystem. HSLU is located in Luzern, directly on the pilot corridor. Partnership confirmed.

Advisory and Oversight Strategic guidance is provided by Dr. Hermann Sterzinger, Chairman of the Advisory Board at TrustNoteD GmbH, with over 25 years of experience working with governments, central banks, and commercial banks. He is co-founder of AUGENTIC, former COO of Veridos, former Group Senior Vice President at Giesecke+Devrient, and served as ICAO operational Board Member for the Public Key Directory from 2015 to 2019. He holds a PhD in Competition and Intellectual Property Law from TUM and lectures there, providing strategic guidance on government-sector solutions and international standards alignment.

Business development is led by Florian Leicher of TrustNoteD GmbH, with over 35 years of experience delivering secure transaction and digital infrastructure solutions to financial institutions and merchants worldwide.

Travellers in Switzerland must manage multiple apps, accounts, and cards across disconnected transport operators — there is no single portable identity that works across all of them.

We propose a user-controlled digital wallet built on Verifiable Credentials, where mobility entitlements are issued once and held by the user rather than scattered across operator silos. Zero Knowledge Proofs allow users to prove entitlement to any operator — train, bus, bike — without revealing unnecessary personal data.

A decentralised operator registry ensures credentials are only shared with verified operators, making trust bidirectional and removing any single point of control.