iotaledger / access-server

Apache License 2.0
14 stars 3 forks source link

[AXS-57] Wallet-based Data Acquisition Plugin #78

Closed bernardoaraujor closed 4 years ago

bernardoaraujor commented 4 years ago

Consider the following scenario:

Alice (device owner) delegates access to Bob for certain amount of IOTA tokens (rent fee) which are transferred from Bob wallet to the device.

Steps:Alice creates new policy with references to:

Subject Bob_ID
Object Device_ID
ActionCost 
request.isPaid
constrains: Time, location...
  1. Policy is placed on Tangle policy store and synchronised with the device automatically though policy updater mechanism.
  2. Bob connects to the device and polls all actions that are delegated to him using Access Secure Networking API.
  3. Some actions will be locked and require payment transaction to unlock. API also provides wallet ID of the device.
  4. Bob creates transaction that contains address of Bob’s wallet, device wallet and amount of tokens. Transaction is stored on IOTA Tangle.
  5. Bob notifies device about transaction.
  6. Upon notification from Bob, device verifies transaction on IOTA. Verification is stored in data acquisition plugin.
  7. PIP contains reference to the payment verification content (request.isPayed) which is used by PDP to calculate policy.
  8. Each time access request occurs, PDP will check whether policy is payed by checking PIP locally.

In order to fulfill steps number 6 and 7, there must be an implementation of a Wallet-based Data Acquisition Plugin.

Wallet funcionality is already available. Any questions should be directed to Sam Chen (@oopsmonk).

In current Wallet implementation, there's wallet_ctx_t, which can be seen as analogous to cli_ctx_t in iota_cmder.

JIRA: AXS-57

bernardoaraujor commented 4 years ago

Useful reference: https://youtu.be/M9dwwgtbbOU

strahinjagolic commented 4 years ago

I have some questions regarding use case stated above:

To @vlad-ns Regarding - 5. Bob notifies device about transaction. Q: How will Bob do this? Should some new interface be added or we can use some existing and, in that case, which one? Can this be sent as a user request, maybe?

To @oopsmonk Regarding - 6. Upon notification from Bob, device verifies transaction on IOTA. Q: How can I verify one specific transaction? By evaluating wallet API, I can see that I can check balance of the wallet, but not sure how to get specific transaction on IOTA tangle?

To @bernardoaraujor Regarding - 7. PIP contains reference to the payment verification content (request.isPayed) which is used by PDP to calculate policy. Q: Is it OK if I add new directory to data plugin (let's call it, e.g. "bill"), which will contain interface for storing transactions and, also, data plugin can check for wanted transaction there, upon request by PIP module?

bernardoaraujor commented 4 years ago

Bob informs the device by sending transaction bundle hash. You can store this hash locally.

Verification of payment is done by passing hash to wallet, which checks tx status with node.

oopsmonk commented 4 years ago

Bob will get a transaction hash after sending out tokens in step 4. Bob needs to give the hash to the device. When the device got the hash it can lunch a confirmation service (https://github.com/iotaledger/access/pull/90) to monitor transaction state for making sure the transaction is valid.

strahinjagolic commented 4 years ago

@oopsmonk I see that this is not merged to master yet, that's why I didn't got it. I will use this API. Thank you.

@bernardoaraujor

You can store this hash locally.

Is the approach for storing it into a data plugin (as mentioned above) OK?

bernardoaraujor commented 4 years ago

@strahinjagolic

Is the approach for storing it into a data plugin (as mentioned above) OK?

yes.

strahinjagolic commented 4 years ago

@oopsmonk Please check changes I've made to wallet.h on wallet_b_data branch. In short - I've expanded parameters of the confirmed_cb. I've noticed that cb will be called if transaction is verified or if time out time expired, but we are not notified if the transaction is verified or not. Also, if there are multiple service confirmation threads, we are not sure which one sent the cb. I tried to solve these problems, by expanding cb's arguments. Do you agree with this approach?

oopsmonk commented 4 years ago

LGFM, please see my comment https://github.com/iotaledger/access/commit/b248fabe18b1fc3f08bd02376c22417169ead266#r39833566

strahinjagolic commented 4 years ago

Done in 3dc417f6bfe5cfaf4a0a2258bf0c319f3e88858c