Transfer approval for contracts should (probably) be based on the contract package hash

[sfeast]

When giving transfer approval to a contract, the current CEP-78 implementation requires the token owner to provide the contract's version hash versus its package hash. The problem is that if the approved contract is upgraded then its version hash will change & token owners will need to re-approve the contract.

get_verified_caller appears to be the source of this issue.

[sfeast]

& perhaps this was intentional? It could make sense that you wouldn’t want to leave approval with a contract that is changing its rules.

[sfeast]

I didn't realize this PR exists, seems that this is already being considered - #99

[RitaMAllenCA]

We have considered this for 1.5 as a modality with the option to use package hash and/or contract hash. However, there are security concerns with using package hash that should be discussed. Will add an agenda item to the CEP-78 advancement meeting.

[gRoussac]

Hi @sfeast, thanks for your report. I merged a PR adding to give the ability for get_verified_caller() to return the package if caller is a contract. Then I added boolean modalities to allow packages to mint / transfer - approve - revoke if they are operator for a token. As you noticed, those options defaults to false and we leave this decision to the collection owner if it wants to allow automatic whitelisting / approvals of versioned contracts.

Those modalities can be opt in on upgrade, however one needs to use set_variables entry point to switch them off, upgrades only allowing to switch those options on.