new feature proposal: preferred email or domain
Ben Adida
Hi all,
We're considering a new feature for BrowserID, "preferred email
pattern", where a site can request a verified email with a particular
pattern, or even a specific verified email.
Two major use cases:
(a) web sites in an enterprise setting may want to authenticate "anyone
with an acme.com email address", and it would make for bad UX if a user
mistakenly picked their home email and then was told "sorry, you need to
use acme.com". Much better to make that part of the flow.
(b) if a web site finds out your identity from a side-channel, e.g. a
link from an email that is bringing you back to the web site for a
particular action, it really only wants you to log in with that
identity, not another one that won't let you complete the action.
So the site would do something like:
navigator.id.getVerifiedEmail({domain: "acme.com"},
function(assertion) {...});
or
navigator.id.getVerifiedEmail({email: "b...@adida.net"},
function(assertion) {...});
The result would be that only the matching identities would be listed in
the BrowserID selector.
I don't think we need/want full regexp in the request. Do we?
We'd love your feedback.
-Ben
Brian Smith
> We're considering a new feature for BrowserID, "preferred email
> pattern", where a site can request a verified email with a particular
> pattern, or even a specific verified email.
>
> Two major use cases:
>
> (a) web sites in an enterprise setting may want to authenticate
> "anyone with an acme.com email address", and it would make for bad
> UX if a user mistakenly picked their home email and then was told
> "sorry, you need to use acme.com". Much better to make that part
> of the flow.
One of the motivations for BrowserID was our realization that websites were standardizing on a few identity providers (Facebook, Twitter, Google) to the exclusion of others--especially first-party IdPs like briansmith.org and adida.net. My understanding is that one way we encourage websites to accept a wide variety of identity providers is by forcing the painful UX above for sites that try to restrict which IdPs they accept.
How are you seeing such enterprisy authentication happening? I would think that most enterprises of this sort would want to be their own IdPs, so that using BrowserID wouldn't make any sense (AFAICT).
Cheers,
Brian
Ben Adida
> websites were standardizing on a few identity providers (Facebook,
> Twitter, Google) to the exclusion of others--especially first-party
> IdPs like briansmith.org and adida.net. My understanding is that one
> way we encourage websites to accept a wide variety of identity
> providers is by forcing the painful UX above for sites that try to
> restrict which IdPs they accept.
I think you're conflating two issues: choosing a subset of IdPs because
of technology, or because of trust. The former is unfortunate. The
latter seems just fine.
Sites limit themselves to Google, Twitter, and Facebook. They tend to do
that because:
(a) they can't get a good enough UX for generic systems like OpenID, so
the NASCAR approach is better
(b) implementing lots of different protocols is too difficult
(c) they get different amounts of data from IdPs, e.g. a lot from
Facebook, not much from Google.
But if a web sites wants to restrict access by domain because only those
users *should* have access to the data why is that bad? Web site
developers are generally logical with respect to their own motivations.
I can't imagine them limiting the scope of email address domains for no
good reason.
(And by the way, if we discover that this is, indeed, a serious problem,
we could still let the user pick another identity, we would just
recommend one that matches first.)
> How are you seeing such enterprisy authentication happening? I would
> think that most enterprises of this sort would want to be their own
> IdPs, so that using BrowserID wouldn't make any sense (AFAICT).
Actually, I think it would make a lot of sense in exactly that use case.
The enterprise would be the primary IdP for its employees, exactly as
you suggest, and then as users go to various partner sites, e.g.
companyname.partnername.com, they would request that users log in with
only a companyname.com email address.
-Ben
Dan Mills
>> How are you seeing such enterprisy authentication happening? I would
>> think that most enterprises of this sort would want to be their own
>> IdPs, so that using BrowserID wouldn't make any sense (AFAICT).
>
> Actually, I think it would make a lot of sense in exactly that use case. The
> enterprise would be the primary IdP for its employees, exactly as you
> suggest, and then as users go to various partner sites, e.g.
> companyname.partnername.com, they would request that users log in with only
> a companyname.com email address.
Concrete example:
mail.mozilla.com (zimbra) could be a primary authority for mozilla.com
addresses.
ldap.mozilla.org/phonebook (the phonebook app) could require a mozilla address.
Ben, I think there's a case for wildcards of some sort, or at least
arrays. e.g., in the above example, at least mozilla.com and
mozilla.org should be allowed in.
Dan
Lloyd Hilaiel
First the use case: Before I got myself a @mozilla.com email address, I used bugzilla.mozilla.org with my personal email address. After I got such an email address, I still used my personal email address out of habit. However certain bugzilla issues are hidden if you do not have a @mozilla.com email address, specifically security issues that could negatively impact users if they were publicized before they were resolved.
I, being a person of moderate intelligence and often operating under great (artificial) haste, didn't realize that my inability to see some issues that I myself was supposed to fix was because I was using the wrong identity.
If bugzilla used browserid, and the authentication dialog somehow highlighted that the @mozilla.com email was *preferred by the site*, then I might have switched to it without having given it much thought, solving a problem without realizing it.
This use case is interesting because it would enable bugzilla to pro-actively help me resolve this issue, and without the feature there's no other way that bugzilla could help. Specifically, it's not allowed to know my identities but wants to tell users who have a @mozilla.{org,com} address that they should probably use that one instead of their personal address.
And an implementation tactic:
There are really multiple features here:
1. site expresses a set of REQUIRED domains for an email address
2. site expresses a set of PREFERRED domains for an email address
3. site expresses a specific preferred email address that the user SHOULD use
4. site expresses a specific email address that the user MUST use
I would suggest, that if we decide collectively that this is a good feature for browserid, then we start with cases #1 and #3. That is, allow the site to express a preference, and visually indicate
preferred emails without preventing the user from choosing a different email address if they so desire. The site itself will have to check the returned email address anyway if there are hard requirements.
Now it's time for the concern:
There is interesting interplay of this feature with another we're eager to implement. That is email->site affinity. If you use an email at a site, the next time you have to pick an identity, the one you last used at this site should be selected by default.
How does this interplay with the preferred email preference of the site? What takes precedent?
In the bugzilla case above, ideally for the user the messaging that "you are not using a preferred email for this site" should be prominent enough to be helpful, but not overly so as it shouldn't prevent me from using an email of my choosing (and no, I'm not proposing we use those words, I don't know how the UX will look). So I guess I'm proposing as a starting point that previous user behaviors take precedence, with site preferences second.
tl;dr; if we go for this, let's start with a minimalistic approach and see how far it gets us. If a site is able to express a preference which too radically changes the set of visible identities or how they're displayed, or adds too much text or new information or flows, I feel like the user will get confused and our already complicated UX diagram (that @shaver comments "has too many boxes") will continue to explode.
lloyd
On Aug 24, 2011, at 8:16 AM, Ben Adida wrote:
>
> Hi all,
>
> We're considering a new feature for BrowserID, "preferred email pattern", where a site can request a verified email with a particular pattern, or even a specific verified email.
>
> Two major use cases:
>
> (a) web sites in an enterprise setting may want to authenticate "anyone with an acme.com email address", and it would make for bad UX if a user mistakenly picked their home email and then was told "sorry, you need to use acme.com". Much better to make that part of the flow.
>
> (b) if a web site finds out your identity from a side-channel, e.g. a link from an email that is bringing you back to the web site for a particular action, it really only wants you to log in with that identity, not another one that won't let you complete the action.
>
> So the site would do something like:
>
> navigator.id.getVerifiedEmail({domain: "acme.com"},
> function(assertion) {...});
>
> or
>
> navigator.id.getVerifiedEmail({email: "b...@adida.net"},
> function(assertion) {...});
>
> The result would be that only the matching identities would be listed in the BrowserID selector.
>
> I don't think we need/want full regexp in the request. Do we?
>
> We'd love your feedback.
>
> -Ben
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
Ibai Garcia
Even if the main topic is longer maintenance windows, the official statement for the mailing list is "how can Mozilla better support enterprises"…and this is totally on topic with that.
In my opinion, is fairly niche use case so it totally depends of the added complexity to the system.
Ozten
complexity to the API?
Having the screen which presents email address be clever about
subdomains and preferring the last used identity would provide some
value.
First time logins (per domain), one could use an advanced sorting
heuristic to surface what is probably the best email address to match
to the current sub-domain.
Later we could experiment with per-domain configuration in the UI:
* ja...@example.com
* ja...@foo.com []hide this email address on example.com
Shane Tomlinson
> Are there enhancements that can be made service-side, without adding
> complexity to the API?
>
> Having the screen which presents email address be clever about
> subdomains and preferring the last used identity would provide some
> value.
> First time logins (per domain), one could use an advanced sorting
> heuristic to surface what is probably the best email address to match
> to the current sub-domain.
>
> Later we could experiment with per-domain configuration in the UI:
> * ja...@example.com
> * ja...@foo.com []hide this email address on example.com
perspective, but I do not think we should hide email addresses, as this
would have potentially blocked Lloyd from logging into Bugzilla using
his non-Mozilla account.
What I am wondering in the proposal is what is the interplay between
"suggested" domains and email addresses that have been previously
selected for a returning user. If Lloyd selected his personal account
to sign into Bugzilla when he last visited the site, which address would
be selected when he visits this time, his @mozilla.com or his personal?
I am guessing something that could easily be user tested to see what
people think.
Shane
Brian Smith
> I think you're conflating two issues: choosing a subset of IdPs
> because of technology, or because of trust. The former is
> unfortunate. The latter seems just fine.
Do we want websites to enforce "real name" policies by only allowing IdPs that have those policies? And/or only allow social networking service X because they have signed an exclusive contract with them? Perhaps I misunderstood the goals of the project, but I thought we were trying to actively discourage websites from making these kinds of restrictions. I think what is proposed does seem likely to be helpful in many contexts, but it is important to recognize that this extension is a tool for building closed identity ecosystems on top of the open protocol. I think that if we can avoid allowing the narrowing of users' choice of IdP, we should do so. I am mostly keen to avoid the situation where websites would force me to either log in with Facebook or not use the service at all, even with BrowserID.
By the way, one argument in favor of this mechanism is that it helps prevent the user from accidentally disclosing identities to the RP that would be useless for authenticating to the RP.
- Brian
Dan Mills
These are real risks, yes. I would be sad if websites decided to only
accept emails from one provider for no good reason.
However, we can't tell the difference between those situations and
other situations where the RP may have perfectly valid reasons for
limiting the email addresses allowed to sign in (e.g., our intranet
requiring a mozilla.com or mozilla.org address).
I think the risks are manageable, and most RPs will want to accept any
email unless they have a good reason not to. Comparisons against
Facebook, Twitter, etc. are difficult, because those require
real-estate and individual development time (since they use similar
but different technologies). In this case the technology is the same
and the screen real-estate requirements do not change whether they
limit valid emails or not.
Dan
Bryan Clark
#1
For the login UX it's fairly easy to add a REQUIRED email type. I think we
can just highlight an existing email address (or set of?) which is required
to use for a certain site. This would likely match the similar designs
we've been working on for when you return to a site and we highlight the
email address you used last time. Most of all I think this requirement is
easy to convey to our audience. "mozilla.org requires a mozilla.com or
mozilla.org email address to log in". The ease of conveying a reason is
something I feel might be lacking for the other features.
If the user doesn't have an email address of this type listed I think we
could look into opening up the "add a new email" input suggesting an email
of the type. This might also require that sites can provide some text to ask
for "A Mozilla corporation or foundation email address". This additional
text description likely becomes more important if we start using even simple
regex type matching "*.mozilla.com" which wouldn't allow us to really reuse
that text.
#2 & #3
Similar to above or how we might recommend the user log in with the same
email they used before we could allow sites to indicate a "Preferred
Email". The only issue I'm slightly concerned with that is how we convey a
bit of the "why". If I created a UI that said something like this: "
bugzilla.mozilla.org prefers mozilla.com addresses" it wouldn't really
reflect the situation. In reality the situation is just as Lloyd described
and I don't think bugzilla would want to seem like it prefers mozilla
addresses over others. Could a certain page in bugzilla could say, this
page requires a @mozilla.com address? Such that you could log in with
anything but you hit a wall and then are required to use a certain type.
We might be able to make something like this happen, it's just not as
straight forward because of the possible complexity of the situation.
#4
I think I understand this one and assuming the flow is always asking for an
ID I actually have then it seems fairly straight forward. I immediately
wondered what we'd have to do if a site asked me for a b...@adida.net email
address which I don't have access to. Not having the exact identity a site
asked for might be a little bit of a complicated flow. The flow also seems
very close to the "you've logged into this site with this email address
before" plus #1 above if we ignore the possibility that you might not have
that address.
Cheers,
~ Bryan
Dan Mills
> #1
> For the login UX it's fairly easy to add a REQUIRED email type.
Yeah, I very much agree with you here. The use-case seems
straightforward to me, and I can see how it could translate into the
UX. We can gray out the email addresses that aren't accepted, describe
the requirement in a legible manner, etc. All good stuff.
> for "A Mozilla corporation or foundation email address". This additional
Hm, maybe we don't need that. I think we can construct something
nearly as good without requiring an additional string from the site,
which brings a bunch of problems (i18n, security, etc).
> #2 & #3
> Similar to above or how we might recommend the user log in with the same
> email they used before we could allow sites to indicate a "Preferred
> Email".
I think the use-cases for preferred email addresses are *far* less
clear than for required ones. I can see how they can logically exist,
but I don't know of any examples in practice. The bugzilla example is
actually not true--mozilla.com addresses do not automatically get
access to security-sensitive bugs as far as I know. Maybe they do get
some other addtitional permissions by default, but I'm not aware of
any.
Even if the bugzilla example were true, I think the use-case is weak
compared to the required case. I'd prefer to punt on this and
reconsider later if we see a clear use-case/demand for it.
Dan
Bryan Clark
> On Mon, Aug 29, 2011 at 2:59 PM, Bryan Clark <cla...@gmail.com> wrote:
>
> > #1
> > For the login UX it's fairly easy to add a REQUIRED email type.
>
> Yeah, I very much agree with you here. The use-case seems
> straightforward to me, and I can see how it could translate into the
> UX. We can gray out the email addresses that aren't accepted, describe
> the requirement in a legible manner, etc. All good stuff.
>
> > for "A Mozilla corporation or foundation email address". This additional
>
> Hm, maybe we don't need that. I think we can construct something
> nearly as good without requiring an additional string from the site,
> which brings a bunch of problems (i18n, security, etc).
>
Ok, I'm just worried about people try to use a *.mozilla.com if that were
implemented. If you stuck with a list of domains we could at least provide
a way to say "email addresses with the domains: x, y, z, ..." and possibly
show the extra ... in some kind of inline popup for a full list. That with
the pattern matching of the domain as they type it in should provide a
decent system.