Deep Into Use Cases

[PedroDiez]

Problem description Provide more info about Use Cases

Expected action Based on discussion output, potential enhancements in https://github.com/camaraproject/BlockchainPublicAddress/blob/2ef709c7b7a132c67f79739441eb9a185a9546a0/documentation/API_documentation/BlockchainPublicAddress_User_Story.md

Additional context N/A

[PedroDiez]

Having as a reference: https://github.com/camaraproject/BlockchainPublicAddress/blob/main/documentation/API_documentation/BlockchainPublicAddress_User_Story.md

Use Case Exposition:

Initial Use Cases are intented to be able to perform transactions between user's blockchains regarding cryptocurrencies or digital assets. Within the scope of this API proposal is the functionality regarding to binding/unbinding a given user's blockchain to a friendly identifier (phone number) as well as to fetch the list of user's blockchains binding to a given phone number.

So by means of the binding association, it can be identified the blockchains with which operate, accessing them vía user's phone numbers.

The fact to bind a user's blockchain (public address) to a given phone number is due to is to make easier to end users and developers the management of blockchains and also a way for Telco Operators to expose this association by means of a natural user identifier.

Based on aforementioned, there are several preconditions or facts when using this solution:

• User's blockchain public address(es) exist in advance. Creation and management of them (e.g. whether different blockchains are managed within a same logical 'wallet' or separately) are out of scope of this functionality.

• In this fashion, How to obtain the User's Blockchain Public Address is also out of scope of the functionality proposal. That is, in the initial case where a user's phone number has not any Blockchain binding yet, response is an empty Array "[]"

• Just for information, in initial Telefonica proposal each blockchain is associated to a specific currency. Nonetheless, other scenarios may appear, based on comment https://github.com/camaraproject/BlockchainPublicAddress/issues/6#issuecomment-1623731808. Then, besides internal checking, if other companies also foreseen cases where transactions between blockchains can be performed for several currencies maybe this model can be re-design to be an optional array so it may (or not) appear based on the possible restrictions over a blockchain. E.g

• One blockchain has no restrictions at all. Parameter is not present
• One blockchain has some restrictions. Parameter (array) is present, indicanting one or more currencies.

[PedroDiez]

Specific comments per endpoint

1) Binding/Unbinding Process POST /blockchain-public-addresses DELETE /blockchain-public-addresses/{id}

Rationale: Only the user of the phone number must be able to perform the bind/unbind as he/she is performed an action over user resources (phone number and User's Blockchain Public Address)

• AuthN: To perform binding/unbinding process user must be identified/authenticated. In On-Net cases (access via Telco Operator Mobile Network), this can be performed vía Mobile IP autenticator, then phone numbr can be inferred from IP. In Off-Net Cases, credentials (user/password auth) or OTP based authentication can be performed.
• AuthZ: Based on aforementioned mechanisms, a 3-legged access token can be issued follow AuthN/AuthZ guidelines https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md, with "authorization_code grant

2) Get Blockchains associated to a given phone number GET /blockchain-public-addresses

Rationale: The object of this endpoint is to obtain the Blockchain addresses associadted to a given phone_number in order to be able to manage transactions. Then this endpoint can be used via 2-legged token (i.e client_credentials grant) as input phone number even cannot belong to the Telco Operator receiving the request, so this case is needed in order to send this request towards end user's operator. Also could be used in 3-legged way (as point 1), however in this case it is not needed the check that input phone number matches with Access Token information.

[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]

I will be closing the issue this week if no further comments about that