FORT: right-proving and attribute-blinding self-sovereign authentication

Salleras, Xavier; Rovira, Sergi; Daza, Vanesa

doi:http://dx.doi.org/10.3390/math10040617

FORT: right-proving and attribute-blinding self-sovereign authentication

License

Citation

Salleras X, Rovira S, Daza V. FORT: right-proving and attribute-blinding self-sovereign authentication. Mathematics. 2022;10(4):617. DOI: 10.3390/math10040617

Abstract

Nowadays, there are a plethora of services that are provided and paid for online, such as video streaming subscriptions, car-share, vehicle parking, purchasing tickets for events, etc. Online services usually issue tokens that are directly related to the identities of their users after they sign up to a platform; users need to authenticate themselves by using the same credentials each time they use the service. Likewise, when using in-person services, such as going to a concert, after paying for this service, the user usually receives a ticket, which proves that he/she has the right to use that service. In both scenarios, the main concerns surround the centralization of these systems and that they do not ensure customers’ privacy. The involved service providers are trusted third parties—authorities that offer services and handle private data about users. In this paper, we designed and implemented FORT, a decentralized system that allows customers to prove their rights to use specific services (either online or in-person) without revealing sensitive information. To achieve decentralization, we proposed a solution where all of the data are handled by a blockchain. We describe and uniquely identify users’ rights using non-fungible tokens (NFTs), and possession of these rights is demonstrated by using zero-knowledge proofs—cryptographic primitives that allow us to guarantee customers’ privacy. Furthermore, we provide benchmarks of FORT, which show that our protocol is efficient enough to be used in devices with low computing resources, such as smartphones or smartwatches, which are devices commonly used in our use case scenario