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.
<keygen> from their HTML vocabulary, which is used to issue an email certificate.
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:
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.
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.