We skipped the TS meeting in the week before 7th Sep to arrange an MVP development plan for a technology discussed much earlier in the year. This note is about the meeting held on 11th Friday at 7pm.
Topics:
Express of trust -> not to the TokenScript digest any more
Express of trust can be done in one of 2 ways: by a transaction to a special express-of-trust address, or by smart contract metadata. Per 2019, we agreed (against Tore's better instinct) that the express-of-trust is expressed towards a TokenScript digest (a specific TokenScript).
Today it's no longer practical thanks to the Ethereum transaction fee. On top of that, Tore has always been right that the key holders and the contract deployer/administrator are not the same people so the trust should be expressed on the signing key, not on individual TokenScript files.
There are 3 solutions:
Express of trust is expressed towards the hash of the signing key.
Express of trust is expressed towards the certificate of the signing key (if exist).
Express of trust is expressed towards the CommonName (in most cases, a domain name).
We decided for the direction of the move but didn't decide which of the two solutions in that meeting, instead, collect a bit of feedback and decide it in the next meeting.
Depoyment unit is the card
Furthermore, a new signing tool is to be made that automatically signs:
all attributes/contracts plus one card.
Repeat that for each card.
Finally, the whole file is signed.
That means, for a TokenScript that has 10 cards, 11 signatures will be produced. It is implied that in each signature only the needed resources are signed with each card.
This allows the deployment - typically, deploy for use on a website - to choose which card to deploy on which web page. Furthermore, a deployment tool will be made so that a web developer can take multiple tokenscripts and combine the relevant information into a single deployable file.
This used to be called "mesh-up" but I prefer not to give it a name as it merely is a deployment method. Instead of saying it's a mesh-up of tokenscript files for depoyment, we simply say that a website builder can deploy the needed cards from various tokenscripts.
I'd like to point out that point 3 was actually dicsucssed 2 years ago and, since it depending on an identifier (domain name or anything certified), we hesistated to use it as the default method.
At that time, Ethereum community was still much made of privacy-sensitive folks who wants to deploy smart contracts anonymously; and we want to allow them to create TokenScript (or someone do that for these anonymous contracts).
One such contract was "King of the Ether".
Now such people are weeded out - I haven't heard the word privacy for a good year; and old acqaintances who chanted privacy now all moved on with their lives doing interesting new jobs unrelated to blockchain. Compared to 2018 where privacy was a hot keyword in all of the "Web is broken - Let's build the new blockchain web with better privacy" blogs.
Practically, today no one uses a smart contract that doesn't have a web domain name associated with it. So this option is back on the table. I'm now in favour of it (compared to 2018 when I wasn't). The reasons are:
A website is a unit of trust, in the sense that no website is of the stewdship of more than one unrelated tokens. Say, AAVE.com are the stewdship of 8 tokens and they are all related. It make sense that all these token's are signed by the same website and the contracts (there are 2 in this case) expresse trust to the site in wholesale.
If using web certificate, Option 2) requires yearly update of express-of-trust. Option 1) too, if best practice for web security is followed. (Unless they use a signing certificate instead of a web certificate, in which case it doesn't matter.)
A website is a unit of trust, in the sense that no website is of the stewdship of more than one unrelated tokens. Say, AAVE.com are the stewdship of 8 tokens and they are all related. It make sense that all these token's are signed by the same website and the contracts (there are 2 in this case) expresse trust to the site in wholesale.
With Express of trust towards the CommonName (in most cases, a domain name), do we need to worry about a domain changing hands?
Yes, but I believe in this context the issue is the same as for TLS certificates for regular websites. In that case, afaik the issue is solved by also using the other fields under Subject Name besides just Common Name. That is, information about the legal owner. Whether one is willing to share this is a different question, but in general if you own a web domain this info will be available somewhere, even if the company is just a shell company. So adding it probably shouldn't leak more than anyone with a search engine would otherwise be able to figure out.
I think maybe Boon is looking at this from the perspective of life-cycle management. So if a domain has changed hand and no longer to be trusted, the smart contract author should do a revocation of express of trust towards that commonName (by transaction or by stopping to show the trust to the domain name in smart contract's return value).
Ah, sorry. I misunderstood the context. In any case I fully agree with your point of doing a revocation transaction in case of closure of a website or changing of administration. I do however think that in practice this might actually happen (people are lazy). So as we have talked about previously, an expiration date should be included as well (as you for example suggest , that express-of-trust must be done once per year is a solution to this)