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.

Regarding the signing of Tokenscripts I believe that what we actually want to do is to have the smart contract’s stewardship, and reputation key holder, sign the Tokenscript provider’s certificate. The rationale is that we would like to avoid signing the Tokenscript itself, as it changes so often. So instead we assert that we trust the people who holds stewardship over the script. That way we don’t need to resign things every time there is an update to the Tokenscript. This could also be combined with the one-key, two certs approach; by signing both the Tokenscript public key and the CA and smart contract certs.

For revocation I think you are right that we need to use a smart contract revocation list.

Another thing I want to mention regarding when certificates are good: I feel that in regards to Tokenscript, and blockchain in general, we would like things to work indefinitely, even if the private key has been lost or a project abandoned. Thus scrips and relevant contracts should not only be signed by the relevant parties, but also by a trusted third party timestamping service. If this is done, then it is possible to trust signatures even if the certificates on the signing keys have expired (assuming none of the certificates have been revoked and that they were all valid during signing)