API Enhancement due to Consent Management

[PedroDiez]

Problem description
Within GET /blockchain-public-addresses endpoint, what is model is the funcionality to obtain the public Addresses of a given phone_number. This is personal information. This API has particularity the personal information is regarding a person which is different of the requesting party.

Purpose of this issue is to evaluate impacts in API and also think about the model of managing this situation. This has relationship with the work managed in Identity&Management WG.

Possible evolution
Not Yet indicated. Firstly Issue to be discussed

Alternative solution
N/A so far

Additional context

To explain scenario following reference image is provided:

In this scenario we have two partys:

• Requesting Party (User A) that wants to obtain information about User B (represented by phoneNumber in API) Blockchain Public Addresses
• Requested Party (User B) that is the User whose information is requested

In the image, case is also showing (informative) when there is an intermediate entity (Aggregator, which may be an Hyperscaler or Operator) just to illustrate.

Two Main Cases:

In both cases, when an aggregator is involved, User B Operator needs to be resolved (by means of Telco Finder GSMA Opengateway feature), commented as informative for image understanding.

• User A (the user the Access Token (Authorization Header) is related to) and User B (represented by phoneNumber) belongs to same Operator.

As serving Operator is the same (let's name Operator1), This Operator will have to check whether UserB has given consent to the App for accessing the info

• User A (the user the Access Token (Authorization Header) is related to) and User B (represented by phoneNumber) belongs to different Operators.

As serving Operator is not the same same (let's name Operator2 for User B). Request has to be routed to such Operator and the checking of the consent will have to be done by Operator 2.

Check of the consent has to be done in the Operator the User B belongs to.
Main topic concern raised here are the following:

• Whether this consent is "forever" or "one time use". Once User B gives consent, anyone copuld access to such an info.
• Whether this consent has to be more fine-grained, so as provided only for the User A access (i.e. have granularity to be settled per user phoneNumber level)

[PedroDiez]

05/OCT NOTES:

• TEF:

From product side main concern is the checking of the permission access from destination user every time a transaction is made may be a stopper for business cases. Maybe some guidance from product view at GSMA OGW may help us to focus a solution.

• VF:

It is needed to ensure restriction/control over the personal information so no one can access to this information

• DT:

Also it is needed to consider the knwoledge of the phonenumber of the user. Knowing the phonenumber can lead to spamming services

[PedroDiez]

Some Use Cases TEF product has commented:

• Use Case: Simplified Cryptocurrency Transactions The "Simplified Cryptocurrency Transactions" use case involves using the "Blockchain Public Address" API to streamline and simplify cryptocurrency transactions within the web3 ecosystem. Instead of dealing with complex blockchain addresses, users can perform transactions using their phone numbers, making the process more accessible and user-friendly.

• Identification in the Web3 Ecosystem: The API is used to link phone numbers with blockchain identifiers, enabling unique identification in the web3 ecosystem. This can be useful for user authentication and verification services.

• Tokenization of Physical Assets: Companies can use the API to tokenize physical assets such as real estate or artworks and link them to phone numbers. This facilitates investment and trading of digital assets backed by real-world assets.

• Customer Loyalty Programs: Businesses can use the API to implement blockchain-based loyalty programs, where customers earn tokens or rewards linked to their phone numbers for loyalty or repeat purchases.

• Voting and Decentralized Governance (DAO): The API can be used in voting systems and decentralized governance, where users vote using their phone numbers to make collective decisions on the blockchain network.

• Gaming Applications: Game developers can leverage the API to integrate crypto gaming features, where players can earn and trade in-game assets linked to their phone numbers.

[PedroDiez]

Feedback from TEF.

Business Unit is making Privacy Assesment about this funcionality, therefore will be kept On-Hold until having their input about this

[PedroDiez]

Privacy Assesment is not yet ready from Business Unit, probably it will happen next year.
So Kept open this issue so far, until having a guidance and extract conclusions to apply

[PedroDiez]

Update 25/ENE/24: No business feedback so far. Pending new checkpoint

[PedroDiez]

As per Meeting 2024-05-02:

• Consent Management Part is kept ON-HOLD
• Topic of not using phoneNumber in clear in GET is managed in Avoiding the use of "plain" phoneNumber as filter criteria of blockchain retrieval #51