We have already been working on this at https://github.com/3nsoft/3nweb-protocols
MailerId is an authentication protocol there.
Its name is styled after BrowserID, precisely because core process of who relies on what, and how signatures are used, -- all of it is borrowed from BrowserID.
The only difference from BrowserID is that provisioning stage is not relying on opening sign-in window, provided by IdP.
This change has following technical advantages:
- When MailerId is packaged as part of the browser (like Persona?), as an extension, or as a baked-in module, browser can use its own privileged UI frame/window/parts, which cannot be spoofed by some rouge page.
- Liberated from browser, this protocol can be used by other apps, in other situations.
In particular, it is used in Authenticated Secure Mail and 3NStorage protocols, for asynchronous messaging and storage respectively.
All server-side services rely on using MailerId for authentication, while in (AweSome) Mail protocol client may rely on it in the first-contact situation for authenticating introductory public keys, passed through mail server.
- A more precise specification of provisioning stage opens a chance to introduce something better.
User still has to have some secret to prove her identity to her IdP.
This secret can be a mere password, with all insecurities associated with handling and storing them on IdP side.
Or, it can be like SSH key-based authentication, so that HTTPS MitM on provisional stage is not leaking user's password to an attacker.
We called this a Public Key Login (PKLogin), where both server and user are assured of mutual knowledge of certain secrets.
IdP has on its file user's public key, while user uses secret part to perform login exchange.
In a common situation, when user derives its secret key from a password (on a client side, obviously), password never leaves a client.
A very strong password deriving routine can be used, like scrypt, working over 1GB of ram, which is prohibitively expensive, when hashing is done server-side, increasing manifold a complexity for password brute-forcing.
In other situations, secret key can be just random, i.e. not derived from any password, which is definitely the most secure setup known to man.
To top it all off, if one desires, it is possible to mix a second factor, i.e. server generates some string, mixes it into crypto challenge, sends that factor via second route, client gets a challenge, and received second factor and completes.
(PKLogin can also be made a part of a browser for those situations where pages still want user to have direct login, benefiting from browser-privileged UI display for a password entry.)
It seems to us that Mozilla's dropping of Persona is a 100% non-technical decision, based on rosy expectation of total market acceptance at moment's notice.
By using MailerId not only on web pages but in a web of some other services, the world can be lured into using this better (private and secure) tech even on web pages.
At this moment, we do not have resources to make a Persona-like integration of MailerId into Firefox or Chrome.
You may do this within this letsauth project.
I hope that you will take advantage of our work, as well as look for places to improve.
We have already been working on this at https://github.com/3nsoft/3nweb-protocols
MailerId is an authentication protocol there.
Its name is styled after BrowserID, precisely because core process of who relies on what, and how signatures are used, -- all of it is borrowed from BrowserID.
The only difference from BrowserID is that provisioning stage is not relying on opening sign-in window, provided by IdP.
This change has following technical advantages:
In particular, it is used in Authenticated Secure Mail and 3NStorage protocols, for asynchronous messaging and storage respectively.
All server-side services rely on using MailerId for authentication, while in (AweSome) Mail protocol client may rely on it in the first-contact situation for authenticating introductory public keys, passed through mail server.
User still has to have some secret to prove her identity to her IdP.
This secret can be a mere password, with all insecurities associated with handling and storing them on IdP side.
Or, it can be like SSH key-based authentication, so that HTTPS MitM on provisional stage is not leaking user's password to an attacker.
We called this a Public Key Login (PKLogin), where both server and user are assured of mutual knowledge of certain secrets.
IdP has on its file user's public key, while user uses secret part to perform login exchange.
In a common situation, when user derives its secret key from a password (on a client side, obviously), password never leaves a client.
A very strong password deriving routine can be used, like scrypt, working over 1GB of ram, which is prohibitively expensive, when hashing is done server-side, increasing manifold a complexity for password brute-forcing.
In other situations, secret key can be just random, i.e. not derived from any password, which is definitely the most secure setup known to man.
To top it all off, if one desires, it is possible to mix a second factor, i.e. server generates some string, mixes it into crypto challenge, sends that factor via second route, client gets a challenge, and received second factor and completes.
(PKLogin can also be made a part of a browser for those situations where pages still want user to have direct login, benefiting from browser-privileged UI display for a password entry.)
It seems to us that Mozilla's dropping of Persona is a 100% non-technical decision, based on rosy expectation of total market acceptance at moment's notice.
By using MailerId not only on web pages but in a web of some other services, the world can be lured into using this better (private and secure) tech even on web pages.
At this moment, we do not have resources to make a Persona-like integration of MailerId into Firefox or Chrome.
You may do this within this letsauth project.
I hope that you will take advantage of our work, as well as look for places to improve.