Proposal: Register with all browser ID's

[Eric Shtivelberg]

I propose having a checkbox when registering to a website called "Register
with all ID's" (or whatever), and when the ID owner registers to that
website he can use any email he has to login to that website.
That way all emails will be tied to one account.

This can be very useful if you have many ID's and you don't want to
remember which ID you have used for a specific website.

I think there are 2 options of implementing this, when the user tries to
log in to a website with an ID other than the one he registered with
BrowserID can tell the website the accounts email and the "display name" or
"display email".

A second way can be just telling the website that this email is tied to
another email already registered(or more) and let the website promote the
user to take action.

What do you think?

Regards,
Eric

[Dan Mills]

I think we would like to provide support for a "backup email"
(allowing separate backup emails per site).

Taking it to the extreme of disclosing all your emails in one go seems
like a non-feature to me, though. What would be the point of the
chooser, or the ability to have different emails?

Dan

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Eric Shtivelberg]

I might have paraphrased it wrong, but I am all for "backup email".

Maybe a better approach would be to have groups of emails, "work","home"
etc. And then when the user logins the first time to a website he can
choose to login using a group instead of one email, that way the backup
emails are all those in that group.
And there can also be a default email for each group.

> What would be the point of the
chooser, or the ability to have different emails?

The point would be having plenty of backup emails, I suggest having a way
of not tying the login to a single email but to multiple emails.


I don't really see how is the "backup email" currently implemented.


Regards,
Eric

[Yvan Boily]

The use case that I can see for this feature is an example where a
user has multiple email addresses, for example, ybo...@mozilla.com and
ybo...@gmail.com. I may want to use my @gmail.com address for most
stuff, but in certain cases I might want to register with an
@mozilla.com address. If a RP accepts multiple email addresses I can
provide my @mozilla.com email address, but also provide my @gmail.com
account in case I lose access to one or the other.

There is also a second case where I might want to sign up with a new
email address but associate an existing profile under another email
address (which Eric covered).

On Nov 19, 3:02 am, Eric Shtivelberg <shedok...@gmail.com> wrote:
> I might have paraphrased it wrong, but I am all for "backup email".
>
> Maybe a better approach would be to have groups of emails, "work","home"
> etc. And then when the user logins the first time to a website he can
> choose to login using a group instead of one email, that way the backup
> emails are all those in that group.
> And there can also be a default email for each group.
>
> > What would be the point of the
>
> chooser, or the ability to have different emails?
> The point would be having plenty of backup emails, I suggest having a way
> of not tying the login to a single email but to multiple emails.
>
> I don't really see how is the "backup email" currently implemented.
>
> Regards,
> Eric
>
>
>
>
>
>
>
> On Sat, Nov 19, 2011 at 5:27 AM, Dan Mills <dmi...@mozilla.com> wrote:
> > I think we would like to provide support for a "backup email"
> > (allowing separate backup emails per site).
>
> > Taking it to the extreme of disclosing all your emails in one go seems
> > like a non-feature to me, though. What would be the point of the
> > chooser, or the ability to have different emails?
>
> > Dan
>

> > On Sat, Nov 19, 2011 at 6:05 AM, Eric Shtivelberg <shedok...@gmail.com>

> > wrote:
> > > I propose having a checkbox when registering to a website called
> > "Register
> > > with all ID's" (or whatever), and when the ID owner registers to that
> > > website he can use any email he has to login to that website.
> > > That way all emails will be tied to one account.
>
> > > This can be very useful if you have many ID's and you don't want to
> > > remember which ID you have used for a specific website.
>
> > > I think there are 2 options of implementing this, when the user tries to
> > > log in to a website with an ID other than the one he registered with
> > > BrowserID can tell the website the accounts email and the "display name"
> > or
> > > "display email".
>
> > > A second way can be just telling the website that this email is tied to
> > > another email already registered(or more) and let the website promote the
> > > user to take action.
>
> > > What do you think?
>
> > > Regards,
> > > Eric
> > > _______________________________________________
> > > dev-identity mailing list

> > > dev-ident...@lists.mozilla.org
> > >https://lists.mozilla.org/listinfo/dev-identity

[Ozten]

Isn't this possible without direct support in the BrowserID protocol?

An RP specific 'user preferences' page that allows a user to 'add more
email addresses'. The [+] button "Add another email address for Sign
In" starts the BrowserID dance and the newly disclosed email is used
to add to the list (instead of as an input to a login flow).

It is annoying to the user to do the three clicks per email address,
but they are totally in control and it is very explicit. (Three clicks
are 1) [+] 2) switch radio selector to another email 3) 'sign in')

The only downside is the semantics are to choose email instead of sign
in, so that feels a bit hackish.

A similar RP specific flow is the merge accounts use case, where 1
user has N accounts under N different email addresses and it makes
sense in the app to allow them to merge these accounts.

[Dan Mills]

Eric, the "backup email" is an idea and isn't implemented yet.

The point of the feature is targeted to helping you recover in case
you lose access to the email address you used to sign up. Disclosing
all your email addresses also has that benefit, but has major privacy
downsides.

In the future, we could think about changes to the API to a) request
multiple addresses, or b) change the "sign in" wordage to something
else. These would make the flow that Austin described pretty smooth.

They're not on the roadmap right now, though.

Dan

[Lloyd Hilaiel]

what do websites do today if you forget your password and no longer have access to the email you used to sign up with?

Seems to me like there are plenty of patterns being applied whichever variations depending on the sensitivity of the account.

I'm a bit skeptical that we need to bake anything special in.

--lloyd

On Nov 23, 2011, at 8:16 PM, Dan Mills <dmi...@mozilla.com> wrote:

> Eric, the "backup email" is an idea and isn't implemented yet.
>
> The point of the feature is targeted to helping you recover in case
> you lose access to the email address you used to sign up. Disclosing
> all your email addresses also has that benefit, but has major privacy
> downsides.
>
> In the future, we could think about changes to the API to a) request
> multiple addresses, or b) change the "sign in" wordage to something
> else. These would make the flow that Austin described pretty smooth.
>
> They're not on the roadmap right now, though.
>
> Dan
>
> On Wed, Nov 23, 2011 at 7:20 AM, Ozten <aust...@gmail.com> wrote:

[Daniel Mills]

Right - that's why we don't do anything special right now. But there is a significant difference, specially once primaries are in the game: loss of an email means immediate loss of your account at all sites you've used that email at. If you forgot to go into each site and change your email to another one (assuming the site supports changing your email) *beforehand* you are immediately locked out and would need to resort to "forgot password + lost email" type flows.

So, I think it makes sense to give users and sites a few extra tools to avoid that scenario. Hence the backup email idea. Maybe it could be a randomly generated @browserid.org email to avoid cross-site tracking?

Dan

On Nov 24, 2011, at 12:34 PM, Lloyd Hilaiel <ll...@hilaiel.com> wrote:

> what do websites do today if you forget your password and no longer have access to the email you used to sign up with?
>
> Seems to me like there are plenty of patterns being applied whichever variations depending on the sensitivity of the account.
>
> I'm a bit skeptical that we need to bake anything special in.
>
> --lloyd
>
>
> On Nov 23, 2011, at 8:16 PM, Dan Mills <dmi...@mozilla.com> wrote:
>
>> Eric, the "backup email" is an idea and isn't implemented yet.
>>
>> The point of the feature is targeted to helping you recover in case
>> you lose access to the email address you used to sign up. Disclosing
>> all your email addresses also has that benefit, but has major privacy
>> downsides.
>>
>> In the future, we could think about changes to the API to a) request
>> multiple addresses, or b) change the "sign in" wordage to something
>> else. These would make the flow that Austin described pretty smooth.
>>
>> They're not on the roadmap right now, though.
>>
>> Dan
>>
>> On Wed, Nov 23, 2011 at 7:20 AM, Ozten <aust...@gmail.com> wrote:

[Joe Devon]

> So, I think it makes sense to give users and sites a few extra tools to avoid that scenario. Hence the backup email idea.<

How about an sms passcode to a phone number? Is this at all workable?

[Eric Shtivelberg]

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

Not every website can do that, infact almost none does except the very very
big companies like Google.

> what do websites do today if you forget your password and no longer have
access to the email you used to sign up with?
>
> Seems to me like there are plenty of patterns being applied whichever
variations depending on the sensitivity of the account.
>
> I'm a bit skeptical that we need to bake anything special in

Infact we do since BrowserID governs the login between the website and the
user and the website, and since we have taken the password out of the
equation the only way to know you are who you say you are is through
BrowserID.
The current patterns are having a secondary email(which most websites do
not support) or emailing the website and asking them to recover your
account answering different questions(if you set any).
>From all the websites I have logged in to almost none support any of these
options.



Regarding the backup email - maybe we could enable a user inside BrowserID
say he no longer has access to an email and from that point forward every
time he uses the unaccessible email to login we tell the website to use a
replacement email the user has chosen as replacement.
That would be easier to implement and would not change any current API I
believe.


PS: I am just throwing ideas for the backup email part which is necessary,
I have thrown here some three ideas feel free to choose(or not :) ).

Regards,
Eric

[Dan Mills]

On Thu, Nov 24, 2011 at 1:00 PM, Joe Devon <joed...@gmail.com> wrote:
>> So, I think it makes sense to give users and sites a few extra tools to avoid that scenario. Hence the backup email idea.<
>
> How about an sms passcode to a phone number? Is this at all workable?

I don't think you should need to disclose your phone number to every
website just for account recovery purposes.

BrowserID could use your phone number to help you recover your
browserid.org account itself--but for it to let you recover the
account on the site we'd still need the backup email.

Dan

[Dan Mills]

> Regarding the backup email - maybe we could enable a user inside BrowserID
> say he no longer has access to an email and from that point forward every
> time he uses the unaccessible email to login we tell the website to use a
> replacement email the user has chosen as replacement.
> That would be easier to implement and would not change any current API I
> believe.

This is equivalent to the backup email idea, trust-wise, and would
require an API change.

When you sign in with one email, BrowserID helps you state "under the
authority of domain.com I claim that I am us...@domain.com" (or in the
secondary authority case, "under the authority of secondary.org I
claim that I am us...@domain.com").

To have BrowserID switch your account on a site to another email, you'd need:

* under the authority of secondary.org I claim that I used to be
us...@old-domain.com
* under the authority of new-domain.com I claim that I am us...@new-domain.com
* set my primary email to us...@new-domain.com because secondary.org says so

It is not possible to trace the old back to the primary, so the only
way is to rely on the secondary (browserid.org). And this opens up
further problems: for how long will secondary.org let me claim that I
used to be us...@old-domain.com? Forever? What happens if there's a new
account created by a *new* owner of us...@old-domain.com? Do we need to
start keeping track of timestamps for when you lost ownership? ugh.

A backup email is a lot cleaner because it lets you set up the
relationship beforehand, so at the time of email change it looks like:

* under the authority of backup.org I am us...@backup.org
* under the authority of new-domain.com I am us...@new-domain.com
* since you have us...@backup.org as my backup email, set my primary
email to us...@new-domain.com

Both us...@backup.org and us...@new-domain.com can be expressed via
primaries, and do not require baking in the secondary as a special
case (even though the backup email *can* be provided by the secondary
of course, in which case the trust model is the same--just cleanly
separated).

HTH,
Dan

[Eric Shtivelberg]

Hehe, didn't realize it was such a problem.

[Joe Devon]

Eric,

>>Not every website can do that, infact almost none does except the very very
big companies like Google.<<

Twilio makes it pretty easy I believe.

Dan,

I only meant as a backup for BrowserId, not for each website.

[Eric Shtivelberg]

On Thu, Nov 24, 2011 at 9:54 AM, Joe Devon <joed...@gmail.com> wrote:

> Twilio makes it pretty easy I believe.
>

Not everyone can afford that unless they are actually selling something or
earning money.

I only meant as a backup for BrowserId, not for each website.
>

Currently I can login with any email address I have added to my BrowserID
account to BrowserID so there's your backup(along with security questions
and cellphone).


Why don't you think we need to have backups for websites?


Regards,
Eric

[Joe Devon]

On Nov 24, 2:05 pm, Eric Shtivelberg <shedok...@gmail.com> wrote:

Eric, not sure I'm following you.

Regardless, I don't think browserid should be telling websites to use
sms, or any backup at all. It's just a service/protocol websites can
use.

Of course they need backups, but it seems out of scope to this mailing
list to bring it up here. Every website has to choose what they do
themselves.

Also, I don't think SMS is beyond the ability of the Mozilla team to
write up. And I think there's a way to do this without a cost for
outgoing sms'es, but I could be wrong.

[Eric Shtivelberg]

On Sat, Nov 26, 2011 at 12:53 AM, Joe Devon <joed...@gmail.com> wrote:


> Also, I don't think SMS is beyond the ability of the Mozilla team to
> write up. And I think there's a way to do this without a cost for
> outgoing sms'es, but I could be wrong.
>

SMS's were suggested by someone else, and I just went along with what has
been said - I was just stating that SMS's are too costly unless your'e
Google or something so I didn't see how can most websites use it at all.

Eric, not sure I'm following you.
>

Like I just said SMS's are costly and I am trying to suggest a way to have
backup logins for a website automatically without having to go to each one
and add a backup email(if it is even supported on that website).


For example: you have created an account on a website with
na...@mail.comand now you've lost access to your email account, and
you forgot your
password or someone else changed it.
What can that website do for you? Absolutely nothing(unless they have a
backup email feature which most website do not have).
Am I missing something? Because as far as I can see your'e doomed.

Regards,
Eric

[Ben Adida]

On 11/23/11 11:54 PM, Joe Devon wrote:
>
> I only meant as a backup for BrowserId, not for each website.

Following up on this interesting thread...

In the case of centralized third-party auth, there is *one* entity
responsible for managing that account (Facebook, Twitter, Google), and
ownership of that account should never be revoked (in theory... in
practice there are cases where those accounts are revoked, and that
situation is pretty bad for those users.)

In a decentralized system like BrowserID, where there are many Identity
Providers with varying account revocation / reassignment policies, it's
conceivable that a user would lose access to their email account and
instantly lose access to the web sites that depend on that account via
BrowserID.

I don't think this will be that common an occurrence, but when it does
happen, a fallback exists only if the *web site* has an alternative way
to identify the user. A backup email address is a good idea.

Austin's point is true: web sites can do this now with two BrowserID
calls. That's why I'm not pushing hard on the backup-email flow. That
said, I think it will be worth considering at some point, so that it can
be a unified flow at signup.

SMS addresses this problem only if BrowserID can deliver a trustworthy
assertion that the user owns a particular phone number. I don't know how
to do that at this point, as I don't think there are distributed trust
chains for phone numbers.

-Ben

[Eric Shtivelberg]

On Tue, Nov 29, 2011 at 5:05 AM, Ben Adida <b...@adida.net> wrote:

> Austin's point is true: web sites can do this now with two BrowserID
> calls. That's why I'm not pushing hard on the backup-email flow. That said,
> I think it will be worth considering at some point, so that it can be a
> unified flow at signup.
>

I am glad we agree that it is worth considering, and if there will be a
public discussion I would be very glad to be part of it.


PS: I think that austin's idea should go into a howto page on the wiki or
something like that.

Regards,
Eric