This meeting revised the MVP for attestation - sending ether to email address or mobile number. And drafted the data objects that need to be attested in each step.
DataObjects
- CSR signed by Bob.
- Email-attestation signed by an authority.
- Cheque signed by Alice.
CSR: TBS by Bob
Either
mail: bob@example.com
Email-attestation: TBS by Email authority
objectClass: inetPersonAttestation
hiddenMail: ๐ฆ
subjectAddress: 0xdecafbad000fed
expiry: 20200505830300.3
Cheque: TBS by Alice (will be used to form the magic link)
objectClass: chequeRedeemEther
walletContract: (probably implied by the objectClass)
amount: 1
redeemer: 0xdecafbad000fed
expiry: 02020508080803.0 (tomorrow)
mailSalted: ๐ฆ'
(secret salt ๐ is sent in the link or separately, not in the cheque)
The attestation is not completed
Sidestep: can this protocol be improved?
The MVP protocol was formed in Weekly meeting #11 half a year ago, where this meeting aims to produce the ASN.X module for the data objects to be attested. However, as James Zaki is new in the weekly meeting he would like to discuss the protocol and we decided to go ahead with that discussion.
James Zaki proposed a two-transaction alternative protocol that spared the use of attestations, email addresses or mobile numbers altogether. As the group chat message is lost when Zoom is closed, the following is reconstructed from Weiwu's memory based on Zaki's key steps.
Assume Alice wish to send ๐ amount of ether to Bob:
- Alice prepares a secret ๐ ;
- Alice sends ๐ and ๐ and a signature on ๐ |๐ to Bob in a secure channel;
- Bob sends a commit transaction to Alice's smart contract with โ(๐ |๐).
- Bob sends a redeem transaction to Alice's smart contract with ๐ , ๐, and Alice's signature on ๐ |๐.
The smart contract recognises that ๐ |๐ is signed by Alice and emits ๐ amount of ether to Bob upon the redeem transaction. A miner can't front-run the transaction by preparing a competing transaction as long as Bob waited a certain block interval between 3 and 4.
The solution has one ease-to-close attack surface that anyone can send a commit transaction similar to the one generated by Bob and not getting rejected since Alice's smart contract doesn't have prior knowledge what Alice would generate and send to Bob in advance. This can be closed by having Alice sending the transaction instead of Bob on step 3 or Bob can submit a blinded signature in step 3 instead of the original signature in step 4.
Weiwu suggested that if a secure communication channel is to be assumed, a send-the-private-key method can achieve the same result with just one transaction. He defines a cheque as a promise-to-pay message that has the amount to pay, the expiry and the condition of payment (an attestation), then the protocol:
- Alice generates a new private key ๐ , and a cheque to the private key ๐ holder. Both are sent to Bob through a secure channel.
- Bob takes the cheque, and produce a self-attestation binding ๐ to Bob's Ethereum private key ๐.
- Bob sends a transaction to Alice's contract with the cheque and the self-attestation.
The smart contract checks the cheque is signed by Alice; checks the self-attestation signed by ๐ that binds Bob's Ethereum private key ๐; and checks the transaction itself is signed with ๐. If all check passes, it emits the amount specified in the cheque.
Compared with the original protocol, both the send-the-private-key method (as well as the two-transaction protocol by James Zaki) have the following disadvantages.
-
Alice has to protect her side. For example, when she sends the email, her mobile is secure and the secret is passed to the email client safely. Wherein our MVP protocol money is protected by Alice's and Bob's wallet and there is no secret that can be used to redeem money without attestation.
-
Bob has to move the money immediately as the communication between Alice and Bob contains the entirety of information needed to redeem the money. Wherein our MVP protocol an adversary which obtained the secret without attestation can't proceed on.
-
Email can't be regarded as the secure channel since the systems involved typically treat emails as privacy instead of a secret. For example, a spam filter plugin might read the email links and keep the data for spam filter training, and such action is acceptable under privacy agreement but not under confidentiality assumption assumed here. Another example is an email forwarder (e.g. Amazon SES) keeping the emails in the log for a number of days. Wherein our MVP protocol an advisory has to actively compromise the email in order to fake an attestation, and Alice can enhance the security by emailing a cheque that requires mobile number attestation instead.
James Zaki pointed out that centralised authority is involved in this protocol, to which Weiwu explained that the line of attestation work here reflected a model rather typical in tokenisation cases - instead of securing the transfer of money, it relies on the appropriate attestation to validate the transactions. This model is seen in many business tokens and the involvement of an attestor is usually already assumed, not added-on. e.g. Bartercard's membership attestation which allows a small business owner to get spare goods and services at a premium price, or, e.g. in the proof of age transaction which allows the purchase of alcohol, the protocol can't work if there is no attestor to attest the buyer's age. So the existence of an attestor is already assumed. Sending ether by email/mobile attestation is one scenario of the protocol instrument we are building.
The attestor model is also seen in other models like W3C's verifiable claim framework, except the attestation stream of work in TokenScript:
- is not assuming that it is an identity that is being attested (e.g. attestation of a job completion in a pay-for-job-completion transaction)
- attestations must be able to be used in transaction payload or to attest the transaction itself (hence small and safe, hence X.509 based)
- the smart contract verifier not assumed of confidentiality.
- not assuming the availability of any parties except the attestation user (at the time of transacting or commit expiry)
In other words, we are not trying to prove that attestation is the only way to solve send-crypto-by-email address scenario but to have a reference attestation use-case that makes practical sense and can be expanded to cover more tokenisation use-cases. Attestation is recognised as a base component back in 2018 (when James Brown wrote the first attestation-accepting smart contract) and this MVP is positioned as a case for that one year later.
