Let's join efforts

[3n-mb]

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.

[callahad]

Hey @3n-mb! Thanks for the summary and pointer. We're still pretty early on in the ideation / prototyping phase. We'll leave this bug open and revisit adopting MailerID once we get the baseline, confirmation email loop working. :)

[3n-mb]

@callahad want to add that current MailerId IdP's code uses direct relationship between IdP and a user, i.e. there is no "confirmation email loop". In this way our code basis are complementary to one-another, if one wants to keep Persona's style "confirmation loop".

What if, besides having "confirmation email loop", in which mail provider has no participation, we give little mail providers (that is not google or yahoo) another standard-based service, that is running MailerId IdP directly.

This way, little guys (protonmail, tutanota, etc.) will have one more security and privacy related, standard service to provide to their users:

• Little guys win, as users will love them more.
• We win, because there will be more little guys, i.e. more diverse and survivable eco-system.
• Security wins when there are many independent IdP's, instead of single huge target for an intermediate compromise.
• For mail providers that have no interest in non-tracking identities (google, yahoo, etc.), who will not run their own IdP, for this case, a third-party place with "confirmation email loop" is a must.

Yes, these are not technical reasons here, but we are not making these systems in the vacuum, are we?

[callahad]

That's absolutely where we want to go, but as with Persona, we have to
start with some sort of universal option (email loop) for when our protocol
of choice isn't supported.

Once we get that squared away, we'll start working on the protocols that
allow for direct confirmation without sending a message, and MailerID may
well fit there. :)
On Feb 10, 2016 11:32, "3n-mb" [email protected] wrote:

@callahad https://github.com/callahad want to add that current MailerId
IdP's code uses direct relationship between IdP and a user, i.e. there is
no "confirmation email loop". In this way our code basis are complementary
to one-another, if one wants to keep Persona's style "confirmation loop".

What if, besides having "confirmation email loop", in which mail provider
has no participation, we give little mail providers (that is not google or
yahoo) another standard-based service, that is running MailerId IdP
directly.

This way, little guys (protonmail, tutanota, etc.) will have one more
security and privacy related, standard service to provide to their users:

• Little guys win, as users will love them more.
• We win, because there will be more little guys, i.e. more diverse
  and survivable eco-system.
• Security wins when there are many independent IdP's, instead of
  single huge target for an intermediate compromise.
• For mail providers that have no interest in non-tracking identities
  (google, yahoo, etc.), who will not run their own IdP, for this case, a
  third-party place with "confirmation email loop" is a must.

Yes, these are not technical reasons here, but we are not making these
systems in the vacuum, are we?

—
Reply to this email directly or view it on GitHub
#1 (comment)
.