Integrate authz module into provenance and use it to transfer restricted marker's

[arnabmitra]

Summary

Integrate authz module into provenance and use it to transfer restricted marker's with permission's from both admin and transferor.

Problem Definition

Original issue is detailed here #261

Basically restricted marker's need permission of the transferor and admin to move.

Authz does provide a standardized way of granting, exec'ing and removing the grant(once exec'ed) and should probably be used.

Disadvantages are more orchestration by client, but that is expected for restricted markers.

Proposal

1. Owner of restricted marker(Transferor) authz grant permission to the admin to move coin
2. Administrator of restricted marker gives authz grant to transferor allow transfer coin(needed to prevent direct invoke of the rpc method)
3. Admin can now transfer coins via authz execMessage(authz allows msg to have only one signer, so signer of transfer obj remains owner of marker, but signer of authz exec becomes the grantee i.e admin here)
4. Owner can transfer too by normal invoke but method now checks admin has given grant(this will be using the authz keeper (i think there has to be custom to remove the admin grant to owner grant once exec'ed)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[iramiller]

This is largely a duplicate of #262

[arnabmitra]

good with closing this

[ghost]

Per proposal 2) above, you'll need to add authz provwasm hooks for smart contracts for when the SC is admin.

[iramiller]

Will be interested in seeing how this plays out... was expecting the case more like 4) above where the source account records an auth for SC withdraw and the SC just does the normal transfer which should succeed because it checks for an existing auth grant... perhaps this isn't how it will actually play out though.

We will probably need some authz hooks in any case... especially if the authz module is used to do something like authorize a secp256r1 address for a primary users phone against their main account which would have wider implications.