Toward Seamless Mobility-as-a-Service

Travelers increasingly demand more sustainable and efficient mobility offers in the sense of a common sharing mobility economy (Ketter et al. 2022; Willing et al. 2017). To date, traveling along itineraries with multiple mobility services is often cumbersome. This process involves many individual steps for each of potentially multiple MSPs; including the selection of suitable services for the different subroutes, time-consuming onboarding or authentication processes to log into booking portals, and payment (Sochor et al. 2018). To mitigate these problems, travelers and MSPs turn to the concept of MaaS, which aims to enable travelers to seamlessly combine different publicly or privately offered mobility services (e.g., car and bike sharing, taxis, buses, subways, rail services, or air travel) with low planning and booking effort (Sochor et al. 2018). In doing so, MaaS intends to provide more sustainable mobility solutions by inducing a shift from personal vehicle ownership to a comprehensive portfolio of public and private mobility services (Willing et al. 2017). MaaS not only means a paradigm shift for travelers but also for competing MaaS who need to collaboratively coordinate their services to enable the seamless planning, ticketing, and payment of services from different MSPs and make use of corresponding network effects (Hoffmann et al. 2021; Smichowski 2018).

Various MSPs have explored how to enable MSPs at both regional and global levels (Willing et al. 2017). These approaches mainly build on centralized systems (Calderón and Miller 2019; Jittrapirom et al. 2017), which typically comprise a proprietary two-sided platform that is operated by a single MSP or a dedicated joint venture between MSPs (Hoess et al. 2021; Schulz et al. 2020). This entity aggregates mobility services and makes them available to travelers for booking. Centralized solutions seem promising because they exhibit strong network effects and offer technical standardization with low implementation complexity (Casady 2020; Esztergár-Kiss et al. 2020). However, existing centralized solutions are limited in their regional scope or in the diversity of integrated mobility services. For instance, some regional and national solutions allow travelers to pay for mobility services via an RFID card or with a mobile app when entering a vehicle (Shaheen and Cohen 2012). While these RFID card-based or app-based systems cover a large set of public mobility services that are not subject to capacity-bound ticketing, they do not allow for booking mobility services in advance and are often restricted only to public services. Other approaches, such as Whim or Moovel, contain a broader portfolio including public and private mobility service offerings (Arias-Molinares and Garcia-Palomares 2020; Santos and Nikolaev 2021). These solutions are, in turn, restricted to specific municipal regions and do not support long-distance travel. Other popular aggregators, such as skyscanner.net or thetrainline.com, have managed to consolidate a global service portfolio but are limited to a single mode of mobility (i.e., flights and rail services, respectively) and thus cannot meet the expectations of travelers who seek seamless multimodal mobility.

Accordingly, centralized platforms have struggled to establish cross-regional stakeholder cooperation between various public and private MSPs despite the apparent presence of positive network effects. They particularly fail to attract a critical mass of MSPs required for a holistic MSPs offering (Schulz et al. 2020). Previous research has hinted at centralized data storage and proprietary protocols and interfaces as key barriers to the adoption of comprehensive MaaS solutions (Bothos et al. 2019; Schulz et al. 2020). These designs lock MSPs into one MSP’s platform and limit opportunities to offer services across different platforms (Constantinides et al. 2018). As a result, centralized approaches entail problems relating to intermediaries’ market power (Nguyen et al. 2019). A potential reason is that such market players may become dominant and may impose unfair market conditions through their pricing of mobility services (Hoffmann et al. 2021). Fearing such behaviors, MSPs resent offering their mobility services via a third-party’s platform when they expect to become dependent on this platform and potentially be subject to price discrimination by a dominant market player in the future (Hoess et al. 2021; Schulz et al. 2020).

To avoid these problems, practitioners and researchers have pointed to decentralized alternatives that establish non-proprietary, interoperable MSPs solutions and offer the participating MSPs opportunities for equal market access while avoiding lock-in effects (Hoffmann et al. 2021; Hoess et al. 2021; Lamberti et al. 2019). In particular, these solutions aim to foster cooperation through the decentralized and transparent exchange of mobility service offerings (Bothos et al. 2019; Stockburger et al. 2021). Technical considerations to decentralized MaaS often include blockchain as a neutral, inter-organizational system for mobility services (Hoffmann et al. 2021; Lamberti et al. 2019; Nguyen et al. 2019). These approaches use smart contracts to represent business logic, streamline processes, increase transparency, as well as automate payments. While such designs arguably address some of the above-mentioned challenges, they face significant obstacles regarding practical diffusion. For instance, in inter-organizational settings, organizations may find it hard to agree on a smart contract implementation that everyone considers fair and reflects all affected businesses’ interests (Kannengießer et al. 2022). The implementation of blockchain-based solutions also entails several operational complexities for MSPs (Sternberg et al. 2020; Toufaily et al. 2021). For instance, blockchain-based MaaS solutions have to meet high demands on throughput and latency while keeping transaction costs low, which may be challenging to meet even with dedicated enterprise blockchains (Guggenberger et al. 2021). Owing to the replicated processing and tamper-resistant storage of information, blockchain-based solutions also face significant issues regarding the handling of sensitive business and personal data (Zhang et al. 2019; Platt et al. 2021; Sedlmeir et al. 2022b). This hurdle stems from the well-known and fundamental trade-off between data confidentiality and the need for availability and related processing of business and traveler data in smart contracts on-chain (Kannengießer et al. 2020).

An alternative to smart contract-based solutions could be provided by SSI and digital wallets for travelers. This approach avoids the replicated and immutable storage of travelers’ personal and ticket data on a blockchain and the complexity of smart contract governance. Instead, sensitive information is exchanged bilaterally between MSPs and travelers. More specifically, travelers store personal data and tickets locally in their wallet in the form of machine-verifiable attestations and selectively disclose relevant identity data to MSPs (Bothos et al. 2019; Hoffmann et al. 2021; Stockburger et al. 2021). Hoffmann et al. (2021) developed a decentralized modular architecture for MaaS based on such digitally signed attestations and blockchain technology. To support traveler authentication, a blockchain provides a decentralized public key infrastructures (PKIs) that equips travelers with globally unique identifiers. However, this approach results in privacy-related problems (Hoess et al. 2023; Schlatt et al. 2022). Hoffmann et al. (2021) also introduce dedicated discovery service providers that use the blockchain to maintain a registry of MSPs and their public keys. As such, they govern market access and support travelers in selecting compatible mobility services. However, it remains unclear which kind of data is stored in these registries. Moreover, while the authors describe that travelers negotiate transport conditions and settle corresponding transactions in bilateral interactions with the respective MSP, they do not specify how travelers identify relevant mobility services and whether smart contracts play a role in the coordination of mobility services.

SSI aims to empower end users to control their digital identities by managing machine-verifiable attestations in their digital wallet, without being dependent on a distinguished identity provider (Weigl et al. 2022; Sedlmeir et al. 2022a). As such, the general concept of SSI is inspired by today’s identity management in the physical realm. An emerging standard for corresponding attestations is verifiable credentials (VCs). A VC is a digital certificate (i.e., it is cryptographically signed) and confirms one or multiple attributes of a subject (Schlatt et al. 2022; Lacity et al. 2023). Digital signatures make VCs less susceptible to tampering than their physical counterparts and allow them to be machine-verifiably presented to third parties (Soltani et al. 2021; Feulner et al. 2022; Lacity et al. 2023). The exchange of these certificates appears in bilateral interactions between issuers and holders, and holders and verifiers, respectively (Sedlmeir et al. 2022a; Mühle et al. 2018). Issuers attest, digitally sign, and transfer these VCs to the holder. Holders then store VCs on their device and, when needed, present them to a verifier (Fig. 1). In doing so, holders generate a verifiable presentation (VP) that can combine and disclose selected identity attributes from multiple VCs in a data-minimizing way instead of transferring the VC directly (Feulner et al. 2022; Babel and Sedlmeir 2023). To digitally verify VPs, verifiers typically rely on public registries that provide additional information about the issuer – for instance, the corresponding public key that allows for the verification of a signature – or on the VC’s state of revocation (Davie et al. 2019; Schlatt et al. 2022). A prerequisite is that a verifier trusts the issuer to truthfully issue VCs (Davie et al. 2019).

To manage their VCs and interact with issuers and verifiers, holders require dedicated software applications (e.g. a mobile app) – referred to as digital wallets (Lacity et al. 2023). Digital wallets are portable applications that allow their users to securely store and manage their digital identifiers and attestations, such as digital representations of ID cards or passports (Jørgensen and Beck 2022; Sartor et al. 2022). Digital wallets give users direct control over their identity information and deploy features to selectively disclose identity attributes (Lacity et al. 2023). They implement message signing protocols, the identification of other entities (e.g., via their decentralized identifiers (DIDs) and the related DID-Auth protocol), support establishing and maintaining secure connections with other entities, and facilitate the storage of VCs (Sartor et al. 2022). Furthermore, digital wallets can implement zero-knowledge proofs (ZKPs) (Sedlmeir et al. 2022a; Babel and Sedlmeir 2023) which allow a subject to prove an identity claim to another entity without disclosing any information beyond what is required. For instance, using zero-knowledge proofs (ZKPs) the holder can derive a proof of being older than 18 at the time of the VP from their VC without sharing the date of birth included in a VC (Lacity et al. 2023). More intricate examples are proofs of non-inclusion of VCs (corresponding to disclosed identity attributes) in a public revocation registry and proofs of hardware binding without revealing the corresponding unique, persistent cryptographic identifiers included in a VC (Babel and Sedlmeir 2023; Feulner et al. 2022).

Issuers and verifiers use cloud agents integrated into their back-ends – as a pendant to travelers’ digital wallets – to sign or revoke VCs, verify VPs, and manage the communication with users’ digital wallets. An advantage of cloud agents running on a server is that they are permanently online and have a persistent IP address. In contrast, messages that are sent to mobile wallet apps need to be relayed by a service that is authorized to send notifications to a wallet app (Hardman 2021). This “mediation agent” is typically operated by the wallet app provider and pushes notifications to the wallet.

To answer RQ1, which concerns the identification of design requirements, and to ground our work on prior knowledge, we conducted an SLR following the best practices outlined by Brereton et al. (2007) and Webster and Watson (2002). We used the search string (“mobility as a service” OR “mobility-as-a-service” OR MaaS) AND (intermodal OR multimodal) AND (transport OR mobility) to cover related work on intermodal and multimodal transport as well as MaaS. We conducted our search using seven databases (Scopus, Science Direct, ACM Digital Library, EBSCOHost, IEEEXplore, Web of Science, and AIS eLibrary). We performed all search runs on full text and metadata. Our initial search returned 2,165 hits, in which we identified and removed 114 duplicates. Next, we screened these results (2,051 hits) in four process steps: (1) title screening, (2) abstract screening, (3)  full-text analysis, and (4) forward and backward search (Brereton et al. 2007; Moher et al. 2009). In each step, we focused on articles that match the following inclusion criteria: the article identifies requirements for MaaS architectures or presents a design or implementation of MaaS systems. We included both centralized and decentralized MaaS solutions to avoid bias and to ground our design on a rich knowledge base (vom Brocke et al. 2015). We excluded articles that are not related to the MaaS domain, or that do not provide any architectural requirements, challenges, or solution approaches. We also excluded articles not written in English. Considering these criteria, we identified 147 articles after the initial title screening that we considered relevant for further analysis. Of these, we classified 21 as relevant after screening all remaining articles’ abstracts. The full-text analysis yielded a subset of 10 relevant articles, which we supplemented with four additional articles we found through a forward and backward search and an additional gray literature analysis using Google Scholar and other search engines (e.g., Google Search). Our final selection thus comprises a foundation of 14 publications.

Owing to the small number of results, we considered the SLR insufficient for deriving comprehensive design objectives that are relevant to the practical environment. In particular, the articles we identified all focus on technical components and do not incorporate business perspectives. Therefore, we decided to enrich our literature study with 17 expert interviews that one of the authors conducted as part of a prior study on decentralized MaaS. This interview set includes experts from 14 different organizations in the mobility services industry, including established MSPs, original equipment manufacturers (OEMs), MSP start-ups, and IT consultancies. Table 1a features the selected practitioners’ and researchers’ backgrounds. All experts were knowledgeable about both the organizational and technical requirements of public and private stakeholders in the mobility sector, as well as the specific business and technical needs for MaaS. The diverse backgrounds of these experts enabled us to complement the requirements for a seamless MaaS solution from the SLR from a broad socio-technical perspective, as suggested by vom Brocke et al. (2020). In these interviews, the experts provided insights on the challenges of current MaaS solutions as well as the requirements and opportunities of an open, decentralized MaaS system. They also discussed the role and current challenges of blockchain as a technical basis for decentralized MaaS. The interviews lasted on average around 51 minutes. We audio-recorded and fully transcribed the interviews and subsequently coded each interview following a two-stage process of open and axial coding (Saldaña 2013). We conducted open coding to gain a first broad overview of the needed requirements and performed the second round (axial coding) to further categorize and condense our findings into generalizable design objectives (Strauss and Corbin 1998).

We carried out expert interviews and a qualitative, criteria-based evaluation to assess the feasibility and usefulness of our MaaS architecture (Venable et al. 2016). With the help of the experts’ feedback, we continually redefined the components and processes in iterative build-and-evaluate loops as suggested by Hevner et al. (2004). We conducted seven ex-post expert interviews. As for the ex-ante interviews, we approached experts from different backgrounds to assess the implementation of our MaaS architecture from multiple angles (see Table 1b).

We conducted semi-structured interviews to generate rich data (Myers and Newman 2007) and applied the following logical sequence (Schultze and Avital 2011). First, we presented our research by suggesting SSI enabled by digital wallets as promising approach to facilitate seamless MaaS. We then presented our prototype in a live demonstration to illustrate our artifact in use and to inform the subsequent discussions. Specifically, our prototype allowed us to demonstrate the processes of requesting and storing travel tickets as well as the subsequent ticket verification from the traveler’s perspective using a digital wallet. In addition to our prototype, we presented our key artifact – the underlying architecture, including components and processes. Following our demonstration, we discussed our design’s feasibility and usefulness, considering the requirements that we had identified for seamless MaaS architectures. To this end, we first asked for open feedback on the architecture and our demonstration. We then discussed the feasibility of our solution and both its fitness and remaining needs for improvement in relation to our design objectives. We focused on the data management implied by our solution, its effects on the cooperation and competition between MSPs, manageability aspects, and opportunities to connect our solution to existing MaaS platforms. Finally, we discussed user experience-related aspects.

Each interview lasted around 58 minutes on average. As for the ex-ante interviews, we audio-recorded and transcribed each ex-post interview and analyzed the transcripts through two cycles of coding. We then applied provisional coding, i.e., we coded the statements based on the identified design objectives and requirements, which served as the initial list of coding categories (Saldaña 2013). This helped us to assess our artifact’s fit. In the second coding cycle, we revised our codes to identify more overarching mechanisms of our solutions and linked our codes through axial coding (Saldaña 2013; Strauss and Corbin 1998). From this axial coding, we derived three DPs for IT architectures for MaaS (Gregor and Hevner 2013).

Successful MaaS implementations need to incentivize various MSPs to cooperate, but this remains a major challenge (Calderón and Miller 2019). This challenge is driven by the prevailing competition between MSPs, their individual goals of dominance in the mobility market, as well as their heterogeneous business interests (Schulz et al. 2020). For instance, the private sector typically seeks to increase revenues or market share while the public sector often considers other gloals, such as reducing the use of privately owned vehicles and expanding the demand for public mobility services (Arias-Molinares and Garcia-Palomares 2020). While MSPs typically compete for providing individual service offerings and selling them to travelers, the presence of complementary service offerings – even provided by another MSP – increases their own services’ value and allows them to benefit from network effects (Jacobides et al. 2018; Katz and Shapiro 1994) (7 experts). Thus, MSPs appreciate some degree of cooperation to foster value creation by levering network effects on both sides (Smichowski 2018; Tomaino et al. 2020). Our experts, therefore, recommend considering the aspect of coopetition (R1) between MSPs (Hoffmann et al. 2018) (17 experts). Regarding the design of a corresponding platform solution, an intermediary role allows MSP to establish strong ties with the customer and maintain or extend their current market share and profits (de Reuver et al. 2009; Schulz et al. 2020). Acting as an intermediary allows an MSP to reduce threats of cannibalizing its own mobility service portfolio, as it grants them control of third-party service offerings. An intermediary role also allows an MSP to protect its own business data and even create value from other parties’ business data (Bothos et al. 2019; Polydoropoulou et al. 2020a). Thus, these intermediaries may gain a monopolistic or at least dominant position in the MaaS domain (Smith et al. 2020). This means that established MSPs are particularly interested in creating and hosting such a platform themselves and managing all customer interactions (Schulz et al. 2020; Smith et al. 2020). On the other hand, MSPs fear becoming merely a service provider when integrating their services and devolving customer interfaces to another MSPs’s platform (Jittrapirom et al. 2018; Sochor et al. 2016) (11 experts). Expert 2, describes this dilemma as follows: “everyone would like to be the central spider on the web. Everybody would like to be the central player who integrates all mobility providers, and everybody is afraid that someone else will become this player, and therefore it hinders these integration efforts, as one would imagine it now.”

To avoid a deadlock that inhibits the establishment of an integrated solution that can unlock value co-creation and network effects, MaaS systems should grant all MSPs the opportunity to maintain their customer interfaces and compete in the mobility market (Calderón and Miller 2019; Lamberti et al. 2019; Mattsson and Jenelius 2015). Therefore, as part of a potential solution, practitioners recommend addressing this problem through disintermediation (R2) (5 experts). Further, a solution needs to provide openness (R3), independent of market power and governance hierarchies, to onboard all potential MSPs as participants of the seamless mobility platform without facing substantial barriers to entry and business-related disadvantages. This includes the opportunity to seamlessly integrate services by different MSPs and to offer their entire service portfolio (Arias-Molinares and Garcia-Palomares 2020; Kamargianni et al. 2016; Paiva et al. 2021) (7 experts). The foundations of such an open system, which also involves a mechanism for the fair distribution of revenues from an aggregate service offer, are trust and the commitment to cooperate among MSPs (Polydoropoulou et al. 2020b).

Previous studies have illustrated that the implementation of efficient MaaS platforms requires real-time data sharing among various MSPs to ensure seamless mobility services for travelers (Surakka et al. 2018). This implies preventing the unintended disclosure and misuse of sensitive business data as well as travelers’ and service providers’ personal data (R4): MSPs typically use data, such as their customers’ identity information, payment histories, transaction references, movement profiles, or habits, to improve their service offerings and gain a competitive advantage (3 experts). Thus, MSPs naturally hesitate to share these data with competitors. Further, they are strictly bound to regulations, such as antitrust laws or the GDPR. These regulations restrict the extent to which MSPs can share business-related and customer-related information with third parties in the absence of explicit need and consent, respectively (Surakka et al. 2018; Paiva et al. 2021) (12 experts). Customers also expect that their personal data will not be shared, particularly to prevent user tracking (R5). In this sense, appropriate data management is necessary to ensure confidentiality and reduce privacy concerns (Cottrill 2020) (11 experts). Since MaaS solutions aim to compose multiple services provided by different MSPs while offering a consistent user experience, sharing required data while safeguarding data protection becomes even more challenging (Expert 16). A solution must also assign well-defined responsibilities and provide clear terms and conditions on how to process sensitive data. This is especially important for ticket issuance and verification as well as clearing and payment processes within a traveling route with multiple sub-routes (Polydoropoulou et al. 2020b; Stockburger et al. 2021).

From a management perspective, the experts stated that a seamless MaaS solution should incorporate modularity (R6) (12 experts). A modular solution involves open and decentralized design concepts, enabling each MSP to offer its mobility services through potentially proprietary yet standardized, interoperable, and accessible interfaces. Modularity and decentralization can facilitate a shared market structure without intermediaries (R2), creating more robust markets than centralized solutions (Bothos et al. 2019; Lamberti et al. 2019; Nguyen et al. 2019). In this context, Expert 4 emphasizes that “the challenge of offering a multimodal and cluster-overlapping mobility platform often fails due to the centrally organized service providers’ different interests.” Ultimately, standardized customer interfaces, for instance, MSPs’ booking applications, are required to prevent the unnecessary development of isolated stand-alone solutions by individual MSPs and to create an interoperable solution (12 experts). These stand-alone modular solutions must support a high number of customer transactions, a characteristic of the mobility market. Thus, a MaaS solution must provide high process efficiency (R7) and consider the aspect of scalability (4 experts) (Sümmermann et al. 2017).

To improve travelers’ user experience, MaaS solutions should enable seamless data sharing (R8) for customers’ identity attributes (Paiva et al. 2021). According to eight experts, one way to achieve seamless data sharing is data portability which enables a “single sign-on” user experience by avoiding tedious registrations with each service. Travelers’ preferences could also be shared bilaterally with different applications, further avoiding vendor lock-in effects from a customer perspective. The current various implementations of mobility services also lead to many challenges concerning cross-system data handling, such as fare management (Lamberti et al. 2019). These challenges require a suitable solution to increase the overall accessibility and transparency for customers (Stockburger et al. 2021) (7 experts). In this context, interoperability and a solution that considers various customer preferences can help address the challenge of application fatigue – the observation that customers are negatively affected by an oversupply of applications (Harper 2020), such as individual MSPs’ mobile apps or web interfaces. An overall solution must also be efficient and quick to use (R7), be open to being rebuilt by each MSP, and reflect the various preferences of different customer segments (Paiva et al. 2021). Ultimately, an interoperable solution that considers a wide variety of customer preferences and a large set of MSPs faces the problem that in the event of an issue with a specific mobility service, travelers must also know exactly whom to contact (Giesecke et al. 2016). When an itinerary involves multiple MSPs’ services, this may lead to inconsistencies of responsibility and liability. Thus, it is important that the MaaS solution clearly defines MSPs’ responsibilities concerning customer support (R9) and makes them transparent to users.

Fundamentally, our architecture employs digital wallets to allow for data portability and in particular the convenient and secure exchange of information between travelers and MSPs (R5). As Fig. 2 illustrates, our architecture covers the three central entities of any SSI solution: MSPs that provide mobility services and act as issuers of travel tickets, travelers who use mobility services (and accordingly receive and present corresponding travel tickets), and travel inspectors acting as ticket verifiers. To facilitate the seamless planning and booking of mobility services for travelers, our architecture comprises an additional entity – the routing service. This service serves as a coordination instance that retrieves mobility service offerings from different MSPs and presents them to travelers. Specifically, the routing service constitutes a complementary modular extension of MSP’s booking interfaces that provides travelers with information on external service offerings (retrieved via open APIs) (R3) without exposing sensitive personal or business data (R4, R5). However, it can also be run as a standalone component for providers that do not offer mobility services themselves. Any MSP can integrate this modular extension (e.g., a municipal authority for transportation, or an international airline) (R2). Thus, our architecture seeks to facilitate coopetition by allowing for the coexistence of proprietary routing services that can be adapted to specific business needs (R1, R6). We built a modular architecture design that empowers MSPs to create proprietary and individual routing services while respecting potentially heterogeneous business needs (R2, R6). Our architecture also incorporates a public data registry that facilitates the efficient verifiability of issued travel tickets (R4, R5). This registry only handles non-sensitive information and, therefore, can be hosted either in a centralized way by a trusted third party or in a decentralized way by multiple MSPs, for instance, on a public blockchain. For communication between these entities, we suggest REST-APIs secured via Hyper Transfer Protocol Secure (HTTPS) for business-to-business (B2B) interactions – in our case, between the MSPs and the routing service. On the other hand, the DIDComm Messaging (DIDComm) specification provides the technical basis for the exchange of personal information between travelers and MSPs. DIDComm has evolved into a common communication standard in many existing digital wallet applications (Sartor et al. 2022). For exchanging travel tickets and other personal information, the architecture relies on the VC and VP specifications.

The MaaS booking process (Fig. 3) starts with the traveler requesting a mobility service by accessing the routing app. The routing app forwards the travel information provided within the request to the routing service controller, which uses the routing search algorithm to identify the optimal composition of individual MSPs’ mobility service offerings. At this stage, the information provided by the traveler comprises only less sensitive information related to the travel itinerary – such as the desired departure time, departure location, destination, price- and comfort preferences, or potentially self-attested (not yet verifiable) discount eligibilities. This practice helps to protect travelers’ privacy and to avoid comprehensive tracking (R5) through the routing service provider. Based on the obtained preferences, the routing service controller utilizes the routing algorithm to identify a selection of suitable MSPs and the corresponding specific subroutes of the itinerary. Thus, an itinerary can consist of many different subroutes offered by different public or private MSPs (e.g. train or air mobility services), or different qualities (from standard to premium mobility service offerings). When travelers confirm their intention to book a specific composed itinerary, the routing service controller dismembers the requested itinerary into the separate subroutes. For each subroute, it creates and forwards to the routing app a specific link, for instance, a public DID that resolves to more detailed contact information for an MSP on the public registry, or the URL of that MSP’s service endpoint directly. Each link also includes the corresponding travel information (e.g., as URL parameters) of the requested itinerary. For instance, if an itinerary consists of two subroutes – \(\hbox {MSP}_{1}\) for subroute 1 and \(\hbox {MSP}_{2}\) for subroute 2 – only \({MSP}_{1}\) receives the required information associated with subroute 1, and only \(\hbox {MSP}_{2}\) receives the required information for subroute 2. Thus, the routing service follows the principle of disintermediation by instructing the traveler’s routing app to connect and introduce themselves to MSPs (R2). By following the link, the routing app requests the corresponding mobility service. The MSP controller receives the request containing the provided information and instantiates a new booking process by persisting the parameters of the subroute as indicated by the routing service’s request and mapping it to a unique booking ID. The MSP controller instructs the MSP cloud agent to generate a new connection invitation and synchronously returns a deeplink to the routing application. Subsequently, the connection invitation is directly accessed within the traveler’s digital wallet, enabling the wallet to authenticate the MSP’s identity and ascertain its trustworthiness via the trust registry, which is then presented to the traveler for perusal. Travelers possess the discretion to accept this connection invitation within their digital wallet, facilitating the establishment of a secure, encrypted bilateral linkage with an MSP. In the future, these connections might also serve as a direct portal for customer assistance (R9).

The process continues with the verification of the traveler’s personal information to transition to the ticket issuance process. Once the traveler and the corresponding MSP are successfully connected, the MSP cloud agent sends a corresponding notification to the MSP controller via a webhook that references the booking ID. Based on the booking information that the MSP controller has stored under this booking ID, the MSP controller creates a proof request that corresponds to the requested mobility service and triggers the MSP cloud agent to send it to the traveler’s digital wallet. The proof request is a standardized, partially cryptographic, representation of the verifiable personal information required that the MSP needs from the user for the booking process. The agent knows how to communicate with the digital wallet based on the contact information associated with the booking ID that was used to establish the initial connection. Technically, this exchange of DIDComm messages between the cloud agent and the wallet involves a mediation agent (as presented in Sect. 2).

By giving consent to the disclosure of the requested identity attributes and creating a VP based on the VCs available in their digital wallet, travelers provide this information to the MSP cloud agent. The digital wallet gives travelers a high degree of control over the presented information (selective disclosure) (R5). For instance, \(\hbox {MSP}_{1}\) could be a car-sharing service provider that requires a valid driver’s license and the traveler’s full name. The traveler can then selectively disclose the attributes that state the full name and the vehicle class for which they have the authorization to drive from their digital driving license. Also, VCs that make a traveler eligible for a discount (they may have been indicated through the booking request already, but not necessarily) can be requested. In doing so, ZKPs (e.g., a proof of possession of a non-expired and non-revoked driver’s license) avoid the disclosure of any information beyond what is requested, for instance, the driver’s license’s serial number or other unique cryptographic identifiers (Babel and Sedlmeir 2023) (R4, R5). By default, the traveler’s digital wallet can even use a new cryptographic key pair in each interaction and nonetheless prove control over the key pairs to which its VCs are bound (Schlatt et al. 2022). Further, depending on the payment method, MSPs may also request relevant payment information, such as a credit card number and its security code. Once the traveler has presented all the required information, the MSP issues the corresponding travel ticket and sends it to the traveler’s digital wallet, which stores the VC for future use. After completing the booking process for subroute 1, the traveler carries out the same process for subroute 2 analogously and bilaterally with \(\hbox {MSP}_{2}\). After that, the traveler is prepared to start their itinerary.

A key feature of the SSI-based booking process is the machine-verifiability of travel tickets. Once a traveler starts their itinerary, the service providers’ or third parties’ travel inspectors may check the issued travel tickets’ validity, in a process similar to the VP illustrated in Fig. 3. To initiate the procedure, the traveler utilizes a QR code furnished by the travel inspector and proceeds to access the corresponding HTTPS link. The travel inspector controller then transmits the request to the travel inspector agent, which expeditiously creates a proof request accompanied by a deep link. As in the case of the MSP’s connection invitation above, this deep link is recognized by the traveler’s edge device, which opens the traveler’s digital wallet to process it. After verifying the identity of the verifying organization (e.g., the travel inspector’s employer that runs the corresponding cloud agent and controller) the traveler sends a cryptographic proof of ticket ownership to the travel inspector agent. The travel inspector agent verifies the ticket’s cryptographic validity, i.e., whether it was digitally signed by the corresponding MSP, and that it has not been revoked, using additional information stored in the public revocation registry. The travel inspector agent verifies the proof and reports the result of the verification and the disclosed personal and ticket information to the travel inspector’s controller. The controller compares the presented content of the ticket to the inspector’s location (start and destination), time (validity date), as well as potentially other properties of the trip, and reports the result to the inspector’s front-end via a webhook. If the ticket is valid, the traveler can continue their itinerary; otherwise, common measures for unauthorized travel will be applied. For services that do not rely on travel inspectors, a static QR code can be attached at the gate of the mobility service or at the vehicle itself.

The experts appreciated the architecture’s design as they considered it a more neutral solution than prevailing centralized MaaS systems. According to Expert 20, the architecture considers the coopetition required for a successful MaaS ecosystem (R1). This can be achieved mainly through the opportunity for MSPs to implement a proprietary routing service by themselves. In particular, our architecture supports the implementation of many coexisting routing services. In this context, Expert 24 raised concerns that the routing service still functions as some kind of service aggregator, resulting in a certain degree of centralization that ultimately may evoke a “monopolist”. However, according to Experts 20, 21, and 23, this is a viable approach to enable fair competition, as each MSP can be a “routing service and then just the best one prevails on the market” (Expert 21). Further, Expert 22 believes that it “is the only sensible solution and also the fastest solution that the market then simply decides which one, which routing service is considered the best, because the user journey is good.” To participate in fair competition and stand out from their competitors, MSPs can modify their routing service according to various customer preferences; for instance, by providing special service offerings or establishing customer loyalty programs. Simultaneously, the co-existence of routing services overcomes the MSPs’ fear of losing a dominant position to a competitor. Expert 19 appreciated our architecture’s decentralized design, as MaaS systems do not need a single intermediary operating a central “routing service, but many different ones” to avoid concentration of market power (R2).

The SSI-based MaaS solution must enable the functionality that all MSPs can seamlessly interact with one another. In this sense, open and standardized interfaces (APIs) (R3) are pivotal to allow MSPs to cooperate in the form of integrating other MSPs’ services within their routing services and to provide an easily accessible onboarding process for MSPs (Experts 22, 23). Expert 23 also perceived the use of open APIs as an enabler for new players to enter the MaaS market “that could not carry the effort to implement a routing services by themselves, so far. [...] And this will foster competition.” Although there is currently no universally adopted standard for developing open APIs, substantial efforts have been made in recent years to facilitate the sharing of mobility service offerings. For instance, the EU’s delegated regulation 2017/1926 related to the provisioning of EU-wide multi-modal travel information services recommends the integration of an “open API for distributed journey planning” which may support a routing service to retrieve mobility service information from various MSPs (European Commission 2017). The European Committee for Standardization has defined a corresponding standard under the reference CEN/TS 17118:2017. In the aviation industry, many airlines have already deployed open APIs to increase their revenue. To make use of the benefits of these open APIs across the aviation industry and promote standardization, the International Air Transport Association (IATA) recently established an open API hub (IATA 2023). These efforts may serve as a promising foundation to implement a routing service as proposed in this work.

To augment coopetition, our architectural framework follows and extends the proposal by Hoffmann et al. (2021) to provide seamless and verifiable interactions between mobility users and MSPs without shifting market power and access to mobility users to intermediaries. According to Expert 19, in the MaaS area there is a particularly strong need for information exchange “which ensures that transactions are executed correctly and also takes privacy into account, so that no more information is transported for a particular transaction than necessary.” In other words, the confidentiality of sensitive business and personal data must be ensured by avoiding their disclosure to third parties and in particular to competitors (Expert 22). Our routing service operates according to this “need-to-know” principle: It does not require the disclosure of any personally identifiable information, such as a traveler’s name or date of birth, to the routing service. The routing service also does not learn whether the traveler has in fact booked a suggested itinerary completely or in parts. Instead, only the MSPs in question receives the information needed to issue tickets associated with the subroutes assigned to them. This approach facilitates cooperation while protecting each stakeholder’s sensitive data from disclosure to third parties. Expert 23 appreciated this approach, as it allows customers to “identify their most suitable mobility offerings and then they have to authenticate in a privacy-preserving way.” Our architecture implements this need-to-know principle by design through bilateral and selective information exchange between travelers and MSPs. Furthermore, we consider secure communication protocols and bilateral data-sharing using interoperable formats for the exchange of verifiable information between MSPs’ digital agents and travelers’ digital wallets (R4) in the ticketing process (Feulner et al. 2022). According to Expert 23, such decentralized digital identity management enables “different opportunities to dissolve data silos than a centralized platform could ever offer so far.” Regarding the exchange of personal data, Expert 22 sees the need “on the one hand, to make the user journey as simple as possible and, at the same time, to ensure personal data protection.” Our architecture facilitates this by building on an open, decentralized identity management solution using digital wallets and a routing service to coordinate these processes. This solution also has the capacity to further minimize the disclosure of personal data (R5) with advanced cryptographic solutions, namely ZKPs.

Consequently, our proposed architecture also does not require any complex B2B contracts that regulate the processing of sensitive and personal data between MSPs. Instead, it only requires coordination at the (B2C) level. This setup enables the more efficient and automated processing of travel bookings (R6). According to Expert 22, the seamless exchange of information without inconsistencies in processing personal data through a single digital wallet enables MSPs to substantially simplify the user journey and to operate much more efficiently (R7). Expert 22 also sees an independent high potential of introducing digital wallets and SSI without the need to change existing processes. In this regard, Expert 22 believes “that there is much value already easily possible through SSI.” Likewise, Expert 23 emphasized that “the question is no longer whether, but only when” digital wallets will be widely adopted for onboarding processes.

Our architecture sought to facilitate booking processes that are as seamless as possible for travelers while avoiding the centralized coordination of MSPs’ services that involve the aggregation of personal information. Our solution achieves this through leveraging digital wallets for a seamless booking process, particularly, efficient and targeted data-sharing through VCs (R8). In this context, travelers have the opportunity to use their identity-related VCs (such as a government-issued ID card, a driver’s license, or a credit card for payment) and present their required identity attributes to MSPs within the ticketing process. Expert 19, therefore, sees considerable potential to improve MaaS-related processes by integrating digital identities: “If we would have an identity and could then simply link them, this would already be a major intermediate step. So even in the current status quo, where we have many different mobility service providers [...] there, for example, barriers to access could be significantly reduced.” This portability of identities not only lowers barriers for travelers who want to use MSPs’ offerings, it also “prevents the risk of vendor lock-in” (Expert 23) of customers. In our architecture, Expert 20 appreciates the usage of digital wallets as an “interoperability layer” that allows travelers to use a booking process that interacts with various MSPs within a single, non-proprietary application. However, in the context of seamless data exchange, MSPs must ensure that travelers at all times know which MSP they can contact in the case of problems with the booking process or the mobility service itself. According to Expert 19, our solution addresses this requirement by providing the technical basis for bilateral communication channels between travelers and MSPs that could also be used for customer support. The connection between the travelers’ digital wallets and MSPs’ cloud agents ensures that travelers at all times know which MSP is responsible for what section of the route (R9). However, while bilateral communication channels can be advantageous for addressing issues with individual services, they may not always be the most convenient option for travelers, especially in cases where problems affect multiple subroutes. For instance, if there are significant delays or disruptions that impact several subroutes of a traveler’s itinerary, travelers will also have to consult with multiple different customer support services. In such cases, our solution may not be able to deliver the same user experience as approaches that provide centralized customer support.

Our research has illustrated that prevailing seamless MaaS approaches do not adequately solve the challenges of the ticketing process owing to the ambivalent role of data and the resulting complex requirements for data processing. While centralized solutions tend to overemphasize competitive needs and demand MSPs to devolve control over strategic data, decentralized, blockchain-based solutions often put too much focus on cooperation and symmetric data access and thereby eliminate opportunities for competition and data protection. In other words, neither fully centralized nor fully decentralized solutions provide sufficient means for fostering coopetition among MSPs. Thus, in line with prior research on coopetition, our design proposes an alternative approach, i.e., the bilateral sharing of sensitive data. In more detail, our design suggests separating the processing of non-sensitive data required for general service offerings from the processing of highly sensitive business and personal data that may constitute a competitive advantage (Gast et al. 2019). In particular, we suggest separating identity management and booking from processes that coordinate entities’ service offers.

A sensible degree of (de)centralization is essential for a routing application that aggregates mobility services offerings. In particular, MSPs aim to retain competitive advantages from processing the users’ preferences indicated in the routing planner as well as advertising and bundling mobility services within proprietary routing applications (Experts 20, 21, 22). As a result, seamless MaaS solutions need to enable every MSP to provide a routing service as an extension on top of its existing customer interfaces to offer customized services that also foster innovation on the side of the routing service (Willing et al. 2017). This approach has the potential to mitigate interdependencies within the MaaS market while still providing the opportunity to gain a competitive edge over other MSPs (Experts 19, 23).

Further, seamless MaaS solutions should employ open standards for APIs to integrate service offerings within routing applications. MSPs also need incentives for providing this data and enforcing non-discrimination. The open availability of service offerings in a cooperative environment provides MSPs incentives in the form of simplified multi-homing in routing planning applications and the resulting enlarged customer base. Such open-standard APIs also reduce the risks of centralization by lowering entry barriers and reducing lock-in effects (Bakos and Halaburda 2020). Nonetheless, these standardized APIs must consider all offerings of the various MSPs, which may lead to increased complexity in governing the entire MaaS ecosystem. Thus, in practice, one needs to limit complexity so that the overall system can be implemented by all MSPs (Expert 24).

Our architecture was built on the assumption that competitors should not be dependent on one another within the scope of their service distribution. Current studies advocate the use of blockchain as a means for fair competition and interoperable cooperation (Hoffmann et al. 2021; Lamberti et al. 2019; Nguyen et al. 2019; Stockburger et al. 2021). Our results suggest that this is not necessarily practical when taking coordination and in particular the protection of sensitive data into account. The replicated processing of booking-related data on a blockchain leads to excessive transparency. On the other hand, when personal data is obfuscated on-chain, some additional data must be passed to MSPs during travel booking via another communication channel in blockchain-based approaches, and smart contracts also cannot process data that is not available on-chain (Sedlmeir et al. 2022b). We suggest addressing these problems by making sensitive personal data portable while maintaining verifiability and ease of data sharing and by giving control over its disclosure to the user. Sensitive data should be only shared in bilateral interactions between the traveler and related MSPs. Bilateral connections between MSPs and travelers enhance users’ control over data disclosure since only the corresponding MSP receives and processes the sensitive user data required for the respective ticketing process. To implement such data-sharing capabilities without compromising user experience, one should rely on a single app. This single app is represented by the digital wallet, which enables self-determined administration of identity documents and eliminates the need for a separate account for every service provider (Expert 23). Further, digital wallets provide high levels of assurance about users’ identity through hardware-binding or credential-linking while at the same time reducing the amount of sensitive information disclosed (Schlatt et al. 2022; Feulner et al. 2022). Such a decentralized approach based on digital wallets serves as a cross-organizational interoperability layer. For instance, credentials such as a personal ID card or driver’s license can also be used and stored within the digital wallet for the verification of required booking-specific data, such as selectively choosing claims such as first name, last name, or the driver’s license when booking car-sharing services.

Fundamental to any new solution, such as our derived architecture, is the organizations’ willingness to adopt such a system and the related business models that may enable them to do so. Thus, we conclude our discussion by elaborating on prospective business models that may underlie and drive the adoption of our solution, in particular, the routing service. One key stakeholder group for the funding and operation of routing services is the public sector. National or local governments or municipalities could financially support routing services or operate their own routing service as part of their national or local transportation infrastructures and citizen services (Hoffmann et al. 2021). They may be particularly motivated to do so to facilitate the use of public transportation and thereby encourage more sustainable mobility behavior. However, our approach based on routing services does not aim to close the doors to the private sector. Different business models may promote privately operated routing services. For instance, dedicated routing service providers may offer additional services, such as travel insurance or advanced customer support. Moreover, routing service providers could generate revenues through the integration of sponsored advertising of certain mobility services. Operating their own routing service might also help to increase MSPs’ own revenues, as offering a larger service portfolio – albeit including services from competing providers – would allow them to increase the attractiveness of their own services (Ritala 2022). Yet, further research is required to investigate the viability of these or other business models and to assess whether they will be able to resolve prevailing issues of MaaS.