From email attestation to TokenNegotiation

Tokenscript Design
1

Boon said:

I was just thinking “Sign in with Attestation (email or phone)” could be a viable product by itself. Many apps use Facebook login for that, it’s verified user account to speed up sign up/onboarding and log in.

The idea of a cryptographic attestation for the email address, I believe, was first made available to the web by Netscape in the 90s. It was called "Email Certificate" by then. I was young, and like today's Victor, I loved to try new things. It's still a mystery why 90s' email certificate failed, but I have the following guesses.

First, as a browser technology, Netscape didn't attempt to push it. The UX remained terrible since the beginning until it fell irrelevant. For example, this is how the login pop-up look like today if your browser has an email certificate in it.

Existing example Firefox Login with Token

The UI is still working as of 2020 but wouldn't be considered acceptable even in the 90s. This technology is not based on JavaScript thanks to its ancient heritage. Today, almost all browsers (except Safari) removed <keygen> from their HTML vocabulary, which is used to issue an email certificate. <keygen> worked without JavaScript - and <keygen>'s functionality, unfortunately, isn't provided by 00s' effort to reintroduce crypto to the web "WebCrypto" - this time through JavaScript - leading to the permanent loss of the capacity to issue an email certificate from the web. Therefore, if you see an email certificate in a browser, it's not issued from the web, but, through the company issued smart-card or pre-configured system setup, limiting its use to corporate.

Second, when the web applications were first invented, security wasn't considered an issue. I remember when I was in college (2002), I attempted to win the IBM Innovation Award with a project. To get an idea of the judge's preference, I hacked into the email account of the Chief Operation Officer of IBM China (the judge). I didn't discover any information useful for winning the competition and thus won the 2nd place (to the younger me it was equal to losing). But I do remember that he was into the porn videos of a certain Playboy girl. (No I don't remember whom - I thought she was a colleague, but then I googled her full name - Google hadn't been kicked out of China yet). I used a simple password crack. People do not look for solutions if security is not regarded as a problem. This is similar to the TLS' story: Pharaon won't let Hebrews go until he loses his firstborn; the industry won't implement TLS until billions are lost.

Third, it turned out that people handle "What you know" better than "What you have". Most people lost their certificates when reïnstalling Windows, which happened once a few months. In general, anything requiring personal management didn't work.

Finally, it's misdesigned. The good folks in IETF decided that it was a transportation layer technology - you start the TLS connection with it (similar to sign-in), then you are safe in it - where it should be an application layer tech. A few reasons that I think it's misdesigned:

  1. Back then the IETF folks didn't have the fine-tuned idea of what is Trust and often mix it with Security. Whether or not you are a rightful owner of an email address (a trust issue) is not the same as whether or not someone can eavesdrop your connection (security issue). As a rule of thumb, in today's web, security is addressed in transportation layer; Trust is always above the transportation layer. In layman's term, you don't say your name then start talking - you talk a bit then reveal your name. Many people stayed on Amazon for hours, logging in only when he is ready to buy something, by the time the connection is already made.

  2. It would be difficult to expand use-cases to tokenised ones if you need more than one tokens to be attested. Let's say that a user enter a session with Amazon using an email certificate, later the user needs to login to MasterPass to pay, he will then need to switch connection since that relies on a different token than email-address (MasterPass membership). You might say in that case he can enter a new connection to MasterPass.com instead, and authenticate and do their business and switch back to Amazon, but today's UX bar is high. Users don't like to go between websites even if the website teleports the user automatically. They love to see things together. American Express, for example, often offer discounts that are not visible at the website at all, so if you made a purchase that satisfies AmEx deal criteria, you often need to come back to AmEx website separately to see if the discount is then applied. Similarly, if you become interested in alcohol, the website should be able to offer them without you switching connection using a new attestation that can prove you are of drinking age (and potentially lose the connection in which you proved your email address).

In my memory, there have been three attempts to reboot the technology. The first time was by Thawte, controlled by Mark Richard Shuttleworth by then. That's when I got my first email certificate (only to learn too few websites support it). Thawte charges their users a few dollars (free for a year) for a certificate, and have the ambition to eventually develop a web of trust so that highly trusted individuals, like Justice of the Peace in today's Commonwealth countries. I looked up and found a few such persons in Beijing and Shanghai, but I was in Xiamen so I was out of luck. I remember it between 2000 and 2002. He gave up that project before he went ahead and founded Ubuntu (the Linux distribution).

The second time was by CACert who doles them out for free, thinking that the cost was the reason people didn't use it. They were wrong. CACert's role is now replaced by Let's Encrypt today, with the caveat that the latter doesn't issue email certificates any more, being a dead tech. Nevertheless, CACert pioneered the idea that attestation to the ownership of a domain or email address can be a free service.

The 3rd time was by a Bitcoin mobile wallet - I forgot its name - in 2016. They failed. They figured that Bitcoin keys, which is used for authorisation, can be used for authentication too (any authorisation - means signing - cryptographic algorithm can be transformed for authentication purpose, as discovered in the 80s). I think they are the first company to have realised that cryptocurrency is also cryptographic technology and can be applied to solve many of the trust issues on the web, eight years after its invention. Talking about the "rapid-changing" world.

Whatever we do, we should not repeat the failures of our "forerunners". Do something differently. TokenNegotiation might be the thing because it can be fine-tuned with React JS framework for very good UX that can't be matched with any traditional tech.

1 Like
2

I think that there are quite a few reasons why email attestation has not caught on yet.

  1. First reason is exactly what you mention; that people have an easier time remembering a password rather than carrying a key around. However, the key issue is generally also there in BitCoin (unless the user uses a broker, which have proved to be bad, time and time again). Still, as we have discussed in here and as we are trying to develop with the threshold backup service, this issue can be mitigated in a secure way.
  2. Since people are still using BitCoin but not email attestations, issue 1. cannot be the only explanation for why it has not taken off. Another reason can be that to use email attestation every provider a user wants to use its attestation towards will need to add code for support for this. There wasn't really any alternative before BitCoin, whereas for email attestation we now have different flavours of Single Sign-On that almost does the same. By almost I mean that a Single Sign-On IdPs are expected to have knowledge of, and verified, a user's mail. Although this is not always explicit.

I think what you are considering to solve here is very similar to some of the things we have tried to solve with the PESTO protocol (and the Olympus project which it is part of). That is, to provide a secure Single Sign-On mechanism, linked to an email address, but not necessarily involving all the sign in and account aspects. That is basically what happens in the full Olympus framework with the PESTO protocol since an IdP has an account associated with a user. This will in practice involve an email and a public key which we can assume the IdP has verified. When the user authenticates it reconstructs, temporarily, its private key, which it uses to sign a nonce (to prove that it could restore it) and returns this to the IdP. The IdP then constructs a token, which can be a standard SAML or OpenID Connect token, that the user can pass on to a service provider. This means that the service provider gets a proof that the user owns a given email, but because of the distributed nature of the PESTO protocol, the IdP is not able to impersonate the user. Furthermore, given that this already is based on a standard it seems that it can prevent the adoption issue.

3

This seems to be a good solution, secure, flexible and good UX

4

can we use DKIM (Domain Keys Identified Mail) for email attestation

5

On the web or on chain?

On the web

tl;dr: Yes, but.

If the domain owner (keyholder of DKIM) is willing, it's attesting power would be as much as the domain owner -> that is, it can attest some key holder owning bill.gates@microsoft.com from the role of Microsoft management.

It's attesting power is similar to last year you (as the CEO) sending a letter to the Polish embassy proving me being an employee. You could have lied but the Polish embassy seems to be happy that they can check the checkbox.

Such attesting power may look smaller than traditional email attestation issuers (like Thawte), but since one can create an email address easily if he is the domain owner, it's pointless for him to fake an email address attestation of his own domain (he can always actually create an email address to make the attestation real), so I'd say yes he can issue email attestations.

One thing to consider is the Sibil attack. In the recent DEVCON cases, it's mentioned that email address is used as a shallow anti-sybil attack mechanism. A 3rd party attestor can implement some anti-Sybil steps (typically, repeatedly ask which ones in the 9 pictures has a boat in it). In such a use-case, DEVCON better say no to DKIM-signed email attestations as it's safer to assume a domain keyholder having no incentive to implement anti-Sybil against their own email addresses.

On-chain

Preferably, they should to use the secp256k1 curve. If RFC draft 6376 finally becomes RFC, it may be possible to have a secp256k1 key as a DKIM key. I have not experimented the gas cost of using other keys in a smart contract which evaluates an attestation. (The email address owner likely uses a secp256k1 key, but the attesting key and the attested key doesn't have to be on the same curve.)

Then they need to issue attestations in a blockchain safe way, which means even though they can re-use the key, they need to use different software (shouldn't be a problem if there are incentive).