You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to be able to verify ownership of an account from within a third party
smart contract. To illustrate the need, I want to create a delivery smart
contract governing the process of ordering a product using a coin account.
In this contract there will be 3 actors:
Buyer
Merchant
Courier
Each of these actors will have their own coin account. From the delivery
account I want a way to assert consent of the 3 actors at various steps
within the process. To give you a few examples:
While Ordering a product I want to have explicit consent of the order details Faciliated via hashing to prevent private info to be stored on chain
While Marking a product as ready for delivery
While picking up a delivery
While receiving the package
The coin account already has a guard that proves ownership of an account.
From the delivery contract I would want to reuse that guard to proof consent.
If the guard would be a simple keyset guard, we could write code like:
Ideally I would want to be able to pass a capability-guard to enforce-guard
and have the above abstract check workout. As capabilities can write to db,
we should only allow capabilities without db writes to pass such guard checks.
Similarly how while enforcing you are not allowed to read from db.
Important to note, the capability being enforced should not be brought into
scope and only tested, as if we are running the defcap as a function within
the body of an enforce. Allowing the guard to have the ability to guard
on multiple contracts without the contract governing the guard to expose
a special function to provide this feature.
The text was updated successfully, but these errors were encountered:
Just as documentation here, I'm unsure whether to close this issue (We've discussed it internally), but the main problem is with this statement:
Ideally I would want to be able to pass a capability-guard to enforce-guard
and have the above abstract check workout.
Simply checking whether a capability can be acquired does not mean it is correct to assume that a user might want it to be. Many capabilities are useful purely as internally acquired tokens, e.g
(defcap INTERNAL () true)
(defconst MODULE_GUARDED_ACCOUNT "some-string-thats-unique-somehow")
(defun f (account:string ...) ; assume there's other args
..
..
(if (= account MODULE_GUARDED_ACCOUNT) (with-capability (INTERNAL) ..) ; do something here
)
Does this necessarily mean that you're approved to create an order from MODULE_GUARDED_ACCOUNT simply because you can pass the acquisition code inside of INTERNAL? Of course not, unless the module code provided it, it is most certainly not ok to assume this would be allowed. The entire point of the cap is that it can only be acquired inside of the declaring module's code.
Capability bodies may or may not perform extra checks and enforces, so capability guards aren't simply a check for "does this code pass", but "have I authorized this as the caller module".
Enforce Capability Guard Request
I want to be able to verify ownership of an account from within a third party
smart contract. To illustrate the need, I want to create a delivery smart
contract governing the process of ordering a product using a
coin
account.In this contract there will be 3 actors:
Each of these actors will have their own
coin
account. From the deliveryaccount I want a way to assert consent of the 3 actors at various steps
within the process. To give you a few examples:
Faciliated via hashing to prevent private info to be stored on chain
The
coin
account already has a guard that proves ownership of an account.From the delivery contract I would want to reuse that guard to proof consent.
If the guard would be a simple keyset guard, we could write code like:
Ideally I would want to be able to pass a
capability-guard
toenforce-guard
and have the above abstract check workout. As capabilities can write to db,
we should only allow capabilities without db writes to pass such guard checks.
Similarly how while enforcing you are not allowed to read from db.
Important to note, the capability being enforced should not be brought into
scope and only tested, as if we are running the
defcap
as a function withinthe body of an
enforce
. Allowing the guard to have the ability to guardon multiple contracts without the contract governing the guard to expose
a special function to provide this feature.
The text was updated successfully, but these errors were encountered: