Tokenscript declares a few smart contracts to be used in its header.
For a TokenScript that manages a token, we need to know that it is trusted by the token's smart contract's stewardship team.
When a TokenScript uses a smart contract, it implies trust to that smart contract, so we need to know who signed the TokenScript.
The straightforward way to achieve 𝑏𝑜𝑡ℎ is to let a TokenScript be signed 𝑡𝑤𝑖𝑐𝑒 with 2 keys.
By the smart contract key - by default the deployment key, if the smart contact doesn't have its own administrative key management functions;
By a reputation key - by default a TLS key, since it's commonly available and you can ascribe a CommonName (the domain name of a website) from it.
This straightforward approach can't work because a TokenScript is updated a lot more frequently than a smart contract. One can update a TokenScript for a simple reason as "adding Russian translation" or "making the collaboration action more accessible (to blind folks)", while these are trivial reasons to update a smart contract. Therefore, the TokenScript's signing key is expected to be used a lot more frequently, while the smart contract key should be guarded more safely. The smart contract key is usually not available when the team wants to update a TokenScript.
Instead of 𝑠𝑖𝑔𝑛𝑖𝑛𝑔 𝑡𝑤𝑖𝑐𝑒 𝑤𝑖𝑡ℎ 𝑡𝑤𝑜 𝑘𝑒𝑦𝑠, we can use a 𝑜𝑛𝑒-𝑘𝑒𝑦, 𝑡𝑤𝑜 𝑐𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒 method.
A TokenScript is signed by a reputation key (the lowest kind of which is a TLS key), with two certificates attached. One from a certificate authority; another certificate signed by the smart contract key.
Regarding revocation, since there is no standard way to revoke a certificate signed by a smart contract, we need either 𝑎) a new EIP for a smart contract in question to express distrust of specific certificates; or 𝑏) deploy a revocation list smart contract.
Sometimes, even 𝑜𝑛𝑒-𝑘𝑒𝑦 𝑡𝑤𝑜 𝑐𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡e method can't work because the smart contract key is not available to sign a certificate. Scenarios:
The smart contract key was discarded after deployment, to publically demonstrate trust, yet there is no commonly agreed way to certify the stewardship's current key for management.
The smart contract is unattended, and someone provided the TokenScript needed for it to function.
A wallet provider (e.g. AlphaWallet) provided a temporary, overriding TokenScript when finding a security issue with the existing one.
So a TokenScript signed only with a reputational key is still acceptable with a suitable level of warning.
Dual-signing creates some security-policy issues with revocation and expiry. For example:
in the case that the certificate from reputation authority expired, but the certificate from smart contract key has not, I feel that TokenScript should be trusted to execute with a suitable level of warning to the user.
in the case that the certificate from a reputation authority is revoked, but the certificate from a smart contract key is not, I feel that TokenScript should not be trusted to execute.