Open PedroDiez opened 11 months ago
05/OCT NOTES:
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.
It is needed to ensure restriction/control over the personal information so no one can access to this information
Also it is needed to consider the knwoledge of the phonenumber of the user. Knowing the phonenumber can lead to spamming services
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.
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.
Feedback from TEF.
Business Unit is making Privacy Assesment about this funcionality, therefore will be kept On-Hold until having their input about this
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
Update 25/ENE/24: No business feedback so far. Pending new checkpoint
As per Meeting 2024-05-02:
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:![image](https://github.com/camaraproject/BlockchainPublicAddress/assets/6905728/dff6c508-5609-47b9-ade4-ab2103642eef)
In this scenario we have two partys:
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.
Check of the consent has to be done in the Operator the User B belongs to. Main topic concern raised here are the following: