MFSSIA Project

Multi-Factor Self-Sovereign Identity Authentication

Multi-factor challenge-set self-sovereign identity authentication (MFFSIA) is an important part for establishing trust between systems, devices, organisations and humans for the emerging machine-to-everything (M2X) economy. Most systems for identity authentication (IA) are single sign-on (SSO), or have fixed challenge sets of limited degree. Additionally, IA systems are controlled by governments, or corporations that are closely affiliated with government entities. The available systems for self-sovereign IA do not offer the necessary flexible configurability of challenge sets. Based on research publications about a formal MFSSIA protocol, this paper presents a blockchain employing implementation for a running case assuming different smart-contract blockchain systems must be connected for sensitive data exchange. The prototype offers a marketplace for challenge-set creation and the challenge/response-lifecycle management employs decentralised knowledge graphs (DKG), oracles for response evaluations.

Together with ONTOCHAIN.NGI.EU, we commenced with our MFSSIA project. This project is backed by a conference paper, a journal paper and a position paper about the machine-to-everything (M2X) economy that is an application case for MFSSIA. Please find here a demonstration video, the source code of the MVP for this ongoing project, and the installation instructions. Furthermore, find here too a (not marketing professional) presentation video about these slides.

MFSSIA

Multi-Factor Self-Sovereign Identity Authentication

Short Description

Depending on the application context, it is possible to flexibly arrange challenge sets that must be correctly responded to for the identity authentication of devices, systems, organisations, or individual persons. These challenges are available in a store to choose from, allegorically comparable to apps in an app-store. This way, many factors determine in a tailored way if humans, organisations, or systems/devices can be trusted for establishing a collaboration connection.

Customers and markets

Creators are able to create challenges that are part of a store in which sets can be configured to sets taking the context into account for which responses are collected for evaluation.

Users can be human, or non-human such as devices, systems, or organisations that want to understand the trustability for collaborating with a counterparty (human, or non-human).

Markets for collaboration are equipped via MFSSIA use with a trustability understanding of the counterparty by applying configurable challenge sets the human-, or non-human counterpart(s) must respond to for self-sovereign identify authentication.

For a transition to Web3, the addition compared to Web 2 is a crypto-wallet coupled with the ability of self-sovereign identity authentication. In that sense, MFSSIA promises to be a key DApp for enabling Web3. Furthermore, we predict the rising machine-to-everything (M2X) economy for which we have produced an open-access journal paper that explains our position. Such an M2X economy is not possible without MFSSIA to establish trust in individualis, organisations and devices/systems.

Customer engagement

The challenge-set marketplace that is allegorically comparable to an app store, engages customers who prepare challenges. This challenge-set marketplace is also an opportunity for other security systems to position themselves, e.g., services for document verification. Oracle providers that facilitate the responses evaluations to challenges are also potential customers. Customer segments for MFSSIA may be the DeFi- and DAO market that require flexibly configurable self-sovereign identity authentication. The other approach for customer engagement is indirect as explained next. As we use DKG and iExec oracle factory for our MFSSIA implementation, their customers may be lead customers of MFSSIA too.

Monetization

The future monetization opportunities for MFSSIA are as follows. With respect to the software, we aim for a freemium open-source business model similar to a linux project.

Challenge creators receive a part of the use fee. Challenge users require tokens to be able to assemble challenge sets. Response evaluators may also be providers of specific oracle solutions that are integrated into and they receive a share of the revenue from evaluating responses to challenges. Security consultants may involve themselves into the challenge/response-lifecycle management and be gathered that way into a separate MFSSIA marketplace. MFSSIA users may demand the security consultancy for a token fee. Further traditional revenue options related to MFSSIA may result from our consulting and customization for lead customers.

Use case Scenario

We describe possible future use-case scenarios below in further details:

Scenario 1 - How it works for challenge creators

Step 1: An organisation and member individual registers to the challenge-set marketplace. Step 2: The challenge is created and the application description added for search. Step 3: A crypto price is set for integrating a respective challenge into a set for use in challenge/response-lifecycles. Step 4: Notifications are sent to the creator for the use of respective challenges for identity authentication. Step 5: Cryptos enter the wallet of the challenge creator per challenge used for identity authentication.

Scenario 2 - How it works for challenge users

Step 1: An organisation and member individual registers to the challenge-set marketplace. Step 2: Challenges are chosen that serve the identity-authentication needs of the user. Step 3: If a challenge is missing, a request may be issued for creation for a token compensation. Step 4: The challenge set is brought to the blockchain for commencing the identity authentication. Step 5: A crypto budget is deposited for financing challenge/response-lifecycles.

Scenario 3 - How it works for response evaluators

Step 1: An organisation and member individual registers to the oracles component of MFSSIA. Step 2: Specific oracles of the response evaluator are registered with MFSSIA. Step 3: The evaluation rate is defined in crypto tokens. Step 4: The oracles engage in the challenge/response-lifecycle evaluations.

Step 5: The crypto wallet of the evaluator collects token compensation for the evaluation service.

Scenario 4 - How it works for security consultants

Step 1: The security consultant signs up with MFSSIA and submits the credentials stating to be able to offer security services. Step 2: The profile of specific security-consulting offers are submitted to MFSSIA together with the rate for consulting. Step 3: Requests for security consulting are serviced. Step 4: Feedback is collected for the quality of security consulting to establish a reputation indicator. Step 5: The token payment for the security consulting is collected to the wallet of the security consultant.

Scenario 5 - How it works for MFSSIA users

Step 1: The user signs up with MFSSIA. Step 2: The challenges are chosen from the corresponding marketplace and arranged into a set for deployment. Step 3: The oracle services are chosen for response evaluations. Step 4: A token budget is deposited into MFSSIA for funding challenge/response-lifecycle evaluations.

Semantic content and content transfer

At this point, we utilise the OriginTrail decentralised knowledge graph (DKG) for capturing context semantics that the MFSSIA solution automatically analyses. Also the challenges are created as DKG instances and the responses too. With this consistent DKG use, there is a uniform format in use for the evaluation of responses to challenge sets pertaining to the MFSSIA application context.

Ownership

The application (back end) will be stored on Github as open source therefore owned by no one. Again, we aim for a Linux-type of freemium approach.

Existing similar solutions/services

The market of MFA is expected to reach a value of US$ 24.1 billion by 2025. Interesting is that the key industries for commercial products are banking, financial service and insurance (BFSI); healthcare; government and defence; travel and immigration; retail and e-commerce. Notable companies involved in multi-factor authentication are – Safran (France), Gemalto NV (the Netherlands), NEC Corporation (Japan), 3M (U.S.), CA Technologies (U.S.), Fujitsu (Japan), VASCO Data Security International Inc. (U.S), HID Global Corporation/ASSA ABLOY AB (Sweden), RSA Security LLC (U.S.), Suprema HQ Inc. (South Korea), Crossmatch (U.S.), IBM Corporation (U.S.), Microsoft Corporation (U.S.), Securenvoy Ltd (U.K) and Watchdata Technologies (China). However, what this short market analysis shows is that flexible challenge-set configurations for the identity authentication of humans and artefacts are a market gap as the established products reach no further than up to 5 challenges.

We show next in a sociotechnical usecase for a B2B transaction that requires more than 5 challenges: The figure below assumes a simple B2B trade of apples from a farmer coop to a grocery-store chain where individual end customers may purchase the apples for their respective households. For this hypothetical B2B business transaction, we assume that the coop and the grocery-store chain have a high degree of automation with ICT systems and also a good degree of process awareness of their transaction. Apples are one of the trade items and there are hypothetically different types available in the coop such as granny smith, fuji, pink lady, and so on.

The assumption is that the coop offers an app for business partners who are interested in searching the agricultural produce on offer. For example a grocery-store chain with many outlets distributed around a country may be interested in purchasing a large amount of apples of a specific type, e.g., granny smith. Since the app is not intended to be used by individual mass customers, we may assume that a pre-registration by business customers is required to allow for an onboarding that is trustable and deters spammers. It is quickly obvious more than 5 challenges are required for trust establishment via self-sovereign identity authentication in such a B2B situation. On the one hand, there are individual employees for the farmer coop, and employees of the grocery-store chain on the other hand. In complex B2B transactions of large payment volume of easily perishable agricultural products, the amount of involved employees may be increased beyond one per organisation. Thus, each respective employee may require a different set of identity-authentication challenge sets, depending on their roles in an organisation, competencies, permissions, and so on.

At the same time also the organisation as such needs to identify itself to the counterparty organisation. Again, depending on the context of a specific organisation with a transacting counterparty, the specific challenge sets may vary and need to be adjusted specifically. Finally, assuming that the coop and the grocery-store chain involve and connect a diverse set of automation systems, we may infer that each one of them also requires an automated challenge/response set configuration. For example, we may assume that a CRM-system is involved on the side of the farmer coop.

The grocery-store chain may connect for automated data exchange its ERP system to the farmer coop. Furthermore, there may be either a third-party financial service provider included that offers crypto tokens, or traditional fiat currency to finance the transaction. Imaginable is also that an insurance provider is involved where a NFT represents the insurance title. Thus, there is scope for considerable scalability in this running case, while we assume to focus primarily on the bilateral cross-organizational transaction scenario where trust must be established between the respective employees who work for the farmer coop and the grocery-store chain that involve automation systems with smart-contract blockchain technology.

For simplicity, we assume that the farmer coop uses a CRM-system that is supported with Ethereum technology, while the ERP-system of the grocery-store chain operates with Hyperledger blockchain technology in support. Finally, to satisfy the requirement of the project, we also assume that the insurance financial service provider uses Tezos for its crypto-token platform that enables the business transaction. For all three organisations involved, it is important to establish trust in the counterparty. We assume that besides the already mentioned cross-organizational connection between the farmer coop and the grocery-store chain, that the latter also connects with MFSSIA to the third-party financial institution that transfers crypto tokens such as ETH for financing the apple transaction.

The case in the figure above furthermore assumes that also technical challenges must be passed. For example, the respective systems of the collaborating B2B partners must be security audited and trust must also established into this aspect. Finally, more challenges must check if gateways are in place and semantically correctly configured for connecting the respective different blockchain systems for sensitive data exchange.

Quality proofs

Given that the basic architecture of MFSSIA Authcoin is present in scholarly peer-reviewed publications (listed above), defined in CPN models that are the result of a well-defined development process, we infer that the software quality is of a high level in the foundation. Note also that CPN carries the fundamental properties of smart contract blockchain systems in that the latter is also a state/transition automate with tokens and programming logics. These properties coincide with the formal properties of CPN. Furthermore, for the scholarly peer-reviewed papers, we used cpntools.org that allows for the simulation and verification of the presented CPN models. Again and in summary, we infer this way that a high level of software quality is given.

ONTOCHAIN partners that support the scenario

We stress that the current MFSSIA implementation has aimed at an integration with other projects in the DKG instances that are used for the semantic capturing of business collaboration contexts as per the running case in the figure above, and also for the definition of challenges. For the evaluation of responses to challenges, iExec oracles are employed for the deliverance of third-party facts. Furthermore, the cross-blockchain connection in the running case between different smart-contract blockchain systems assumes the use of PerunX gateways. Note also that SSO identity authentication systems in ONTOCHAIN such as Gimply now have the option to extend themselves to a configurable multi-challenge set solution with a future MFSSIA integration. Note that an addition/alternative for DKG use in MFSSIA is OntoSpace once this project reaches a sufficient level of development maturity.

With respect to future business value for the ONTOCHAIN ecosystem, the ADOS project that has agreed on a MFSSIA collaboration, focuses on a blockchain-decentralised protocol provision for connecting IoT devices to thereby overcome the bottleneck of the currently prevalent centralised architecture for IoT systems. Consequently, a trust issue occurs when respective devices are integrated with each other into an IoT system and the trust issue compounds during the subsequent lifecycle. Currently, a lack of standards exists for securely connecting IoT devices and their composition yields a very heterogeneous technological landscape. The respective lifecycle stages of an IoT device commence with the initial connection into a system, next the devices establish and terminate connections to other devices for sensitive data exchange, to finally be respectively decommissioned for a possible replacement with a different device. At each stage of the lifecycle, specific security challenges occur that require in principle the passing of challenge/response checks to assure that no attack vectors arise. Allegorically, the security situation is comparable to a mediaeval city with a castle wall. Once the attacker can weaken and tear down a part of the castle wall, it can penetrate and loot the city interior. Thus, if an attacker succeeds in penetrating an IoT device merely once at a certain lifecycle stage, then the consequence is that potentially all the sensitive data sets of the entire overall IoT system are exposed to the attacker. With MFSSIA, each lifecycle stage of an IoT device can be addressed with specifically configured challenge sets to prevent attack vectors from arising for an entire system.

The PiSwap project about NFTs addresses true price-value discovery. The question arises how trust in the legitimacy of a respective NFT can be assured? Also in this context, challenge sets can be configured with MFSSIA for determining the legitimate origin of a respective NFT for adoption into a price-discovery process with the PiSwap project.

There are many integration options with the other ONTOCHAIN projects as they all must tackle trust issues, as the following discussion shows in several examples. The REPUTABLE project about a provenance-aware decentralised reputation system for blockchain-based ecosystems is very symbiotic to MFSSIA in that the former can deliver reputation facts that can be integrated as responses to corresponding challenges. Thus, with an integration into MFSSIA, the REPUTABLE project can extend the amount of possible use cases considerably.

The PS-SDA project automates the GDPR compliant agreements for private data use. Since the MFSSIA project uses diverse datasets, MFSSIA could achieve with a PS-SDA integration the GDPR legal compliance that is stipulated as a goal in Figure 2. Since the duration of this ONTOCHAIN project is very short, an integration with PS-SDA is future work.

While MFSSIA currently limits the use of oracles for challenge/response evaluations to iExec, future collaboration work should also integrate oracles from the projects termed DART and DESMO-LD. The former is a framework for distributed oracles for privacy-preserving data traceability. The latter project is also an oracles project for trusted linked data of a quality degree to provide data evidence in quality and compliance audits, detecting anomalous conditions in industrial IoT or in environmental monitoring devoted to mitigating climate changes. The integration of MFSSIA with such additional specific oracle projects promises to enhance the evaluation power in the challenge/response-lifecycle management.

The DW-marking project focuses on blockchain-based trading of very large datasets. The core problem is to prevent with the use of blockchain technology the involvement of dishonest data sellers on the one hand and malicious buyers on the other hand. Again, with an MFSSIA integration, the probability of including trusted data sellers and buyers can be enhanced.

The GEONTOLOGY project uses a specific algorithm termed proof of offset (POO) for geo-locating data sets. Consequently, an awareness can be established about the country of dataset origin. For MFSSIA, a GEONTOLOGY project integration creates a POO availability for challenges about countries of origin for datasets. Such a country-or-origin targeting challenge/response capability is important for a secure European data-trading market of the future.

The SOLID-VERIF project achieves with blockchain means the verification of credentials, which is again an integration candidate into MFSSIA for enhancing the challenge/response capabilities. For example, our running case of Figure 4 assumes the need to check a security certification for the Ethereum-based system of the farmer coop and the hyperledger-based system of the grocery-store chain. We expect with an integration of SOLID-VERIF to considerably facilitate such a security-certificate check that our running case assumes.

The TENACIOUS project addresses very interestingly a problem of creating trustworthy semantics-aware interoperable cloud services. The service-level agreements that the TENACIOUS considers for achieving an interoperable service marketplace is also an option for extracting challenge sets that support the rapid composition of cloud services.