May 4, 2021

Technical Document – Part 4

5 MIN READ – TEAM XSL LABS

Technical Document – Part 4

“I am not one and simple, but complex and many.”

“Verifiable Request”

We saw at the end of the previous post how a service provider could ask a user to provide a Verifiable Credential by presenting several pieces of information such as a domain name, the type of Credential requested, and a “challenge”. This information is presented to the user via his identity wallet’s interface for him to make the decision to provide (or not) a Verifiable Credential with the knowledge of the context of the request. This is already a satisfactory and not very complex first step, but it is possible to go further if the Verifiable Credential requester is part of the ecosystem and already has his own decentralized identity.

The initial request can then be enriched with:

– a reference to the DID of the requester

– a date

– a context reference (e.g., a text) chosen by the requester, presented to the user

– a signature for this request.

Figure 4-1: Possible links that can be integrated into a VC request

Figure 4-1: Possible links that can be integrated into a VC request

It then becomes possible for the user to verify the identity of the requester through this now mutual authentication.

This possible signature of the request can bring other advantages than a simple identification of the requester and it becomes possible:

– to verify the legitimacy (or even the legality) of such a request based on this identity.

– to associate this request with a contract of conditions of use via the context reference (this contract can also contain references to offered counterparts)

– to prove that such a request existed (at a date signed by the requester and verified by the wallet user).

Without going into detail here, this “signed” framework of contractualized uses of Verifiable Credentials requests allows the user to verify possible rewards related to the provision of these Verifiable Credentials, and even to claim them if necessary.

 

Requesting and providing VCs between apps

A third-party app can call the identity wallet app to make a local request. The third-party app sends a request (with or without linking it to its own decentralized identity) to ask for a Verifiable Credential proving that the “One” user is of age (“over 21” VC).

Figure 4-2: A third party app requests a Verifiable Credential via a local call to the wallet

Figure 4-2: A third party app requests a Verifiable Credential via a local call to the wallet

The wallet can return the VC in the form of a Verifiable Presentation, directly to the requesting app or to a web service passed as a parameter.

 

Requesting and providing VC from a web site

A web service can make a request for a Verifiable Credential to the identity wallet app by presenting its request as a QR Code displayed on its own website or by going through an intermediary server that performs this display for it (or pushes the request if the wallet is already listening to this intermediary server).

The wallet processes the request made via the QR code and returns the Verifiable Credential in the form of a Verifiable Presentation, directly to the requesting website or via an intermediate server.

Figure 4-3: A web service requests a Verifiable Credential via a QR Code and/or an intermediate server

Figure 4-3: A web service requests a Verifiable Credential via a QR Code and/or an intermediate server

 

Anonymous Credential & Multiple Identities

In order to improve privacy, to limit the cross-referencing of information by external actors, and to enable stricter selective disclosure, we are closely following the work on Anonymous Credentials (sometimes also called “AnonCred”). Some cryptographic implementations are unfortunately not necessarily available on the Secure Elements in mobile phones. We will share the results of our research in future articles.

It is also possible to limit unwanted connections between different identity attributes by creating different sub-identities, some of which are only available in a “pseudonymous” form.

Part of the study of these and other, sometimes non-excludable, methods will be left to a qualified research laboratory.

 

An active wallet that knows the identity of its holder (the beginnings of Cortex)

Decentralized identity is often mentioned as a way to prevent or at least limit the dispersion of personal data, and it is indeed desirable for the user not to see his complete profile escape his control. However, there are situations where the user might consider that it is in his interest to provide some information to content producers or targeted advertising campaign tools.

It is not necessarily obvious how to set a fair limit on consent to share even partial personal information. It also makes no sense for the user to share information in the first step of the commercial contact that is the display of an ad if once exposed to it the user has no interest in it.

However, it is possible to reverse the situation if it is the wallet (or a browser/other application connected to the wallet) that knows locally the attributes of its user and fetches on a non-traceable space the advertising message that best matches his interests.

As the advertising industry is eager to measure the success of the targeting of these ads, it is still possible to have an indirect statistical feedback on these targeted displays, on the success of the engagements that follow, without betraying the will to respect the privacy of the people who accept to be “targeted”.

To avoid the cross-referencing of indirect information, however, targeted campaigns will only be carried out with people who match the desired filters. Other countermeasures are also possible to keep an exposure that blurs the tracks of the usual tracking techniques.

This type of isolated and reversed communication channel makes it possible to receive targeted messages without revealing unnecessary information in this first stage.

Figure 4-4: An advertising communication channel that limits tracking and the sharing of personal data

Figure 4-4: An advertising communication channel that limits tracking and the sharing of personal data

 

The second step, which consists of a closer, consented contact for data collecting, could also preserve personal data in the future with the implementation of messaging / chat / chatbot without the use of cookies, IP addresses, etc.

It might even be possible in the future that the most sensitive information such as personal addresses for physical deliveries will not be needlessly shared as it is now partly possible for deliveries in stores, parcel relays, lockers/consignes, collection centers, etc.

 

Punish and reward “advertising” via verified reviews and a reliable reputation

If you are used to social networks that never clean up themselves (such as Facebook or YouTube), you have certainly already sighed at the incredible increase in advertisements for notorious scams (sellers of poor-quality products, sectarian training, Vitalik fake air-drop, etc.).

These new communication channels with reliable but preserved identities, make it possible to trust more the refusals and alerts reported by users exposed to these fraudulent campaigns.

This very notion of verified reviews goes beyond the simple framework of exposure to an advertising campaign and can intervene much later in the customer relationship (post-sale). There are many other moments and situations where the wallet can change the relationship of trust between the targeted population of which it is part and the advertising campaign but also between the population of verified buyers of which it is part and its seller. The communication channel can be maintained, and for once, to the benefit of both parties.

 

Copyright © 2020 XSL Labs – All rights reserved