BrowserID problem statement?

[Benjamin Smedberg]

Is there a page describing the problem that BrowserID is trying to
solve? I keep wandering around starting at browserID.org and I just
can't find a problem statement. There are pages for users and developers
explaining how to use it and set it up, but nothing really explaining
why it is better. If there is a goal/problem statement in a coherent
form, can we please get it linked from the browserid homepage?

I'm asking this because I've joined this group recently and I've been
reading some of the extended conversation about "email address" as the
primary identifier token.

It seems that the primary problem statement is:

* users are currently insecure because they use a separate login for
each site, but often use the same passwords; a malicious site could
phish other sites
* current "shared login" systems such as facebook connect leak private
information about visited sites back to facebook.

The secondary problem statement might include:

* The browser is a good place to store additional details that sites may
need, such as a physical address or credit card information for making
purchases. In the future we'd like the browser to act as a mediator for
this information, rather than having users retype it into each site.

I really don't think that this problem statement should *require* an
addressable email, at least exposed to sites. Certainly some sites may
want to require that they be able to communicate with users via email
(e-commerce comes to mind quickly), but others may just want to
communicate to you via facebook, or twitter, or text message... Your
addressable email address is just like your credit card number or
text-message/phone number; an optional piece of data you can decide to
give to a site on a case-by-case basis.

There are many "secondary" sites that I currently do log into just for a
personalized experience, but to which I don't want to ever receive
email. I also run the mozilla weekly-updates site, which tries very hard
not to require an email address if the user doesn't care to provide
one. but the primary reason why I currently want to give them that
information is for password-reset purposes. Since browserID removes the
need for general password-reset, I don't particularly want to give
flickr, or atc-sim.com, or many other sites, an addressable email.

My girls don't have email addresses and probably won't until they are
quite a bit older, but I have created accounts for them at a few sites;
if these sites moved to browserID, I would have to basically either
create multiple browserID accounts attached to my own email (is this
even possible?), or create dummy emails that I use just to set up
browserID and then delete those email accounts.

Ben Adida said a while back that "relying parties still get an
addressable email address" while Dan Mills said "Also note that the
verified email spec doesn't assume email addresses are actually SMTP
routable." Those statements seem directly at odds with eachother. Which
is it?

If I decided that I wanted to implement my owner provider that gave
identity assertions for som...@anonymous.smedbergs.us with the explicit
understanding that these were not meant to be addressable emails...
wouldn't most websites (Relying Parties) still need to do their own
email verification step in the case where they actually required an
addressable email?

--BDS

[Mike Hanson]

Hello, Ben -

You raise many of the problems that bedevil any attempt to create an internet-scale identity system. Crafting a system that is memorable, fully-distributed, anonymizable, and supports directed (e.g. single-identity-per-site) identity tokens is incredibly difficult, and has many hard corner cases.

I put my own thoughts on this down in my blog a while back, with the first version of the protocol proposal, here:

http://www.open-mike.org/entry/verified-email-protocol
(the introduction section sets out my thoughts on the problem statement)

You'll note that I, at least, am not particularly wedded to the idea that a browserID-asserted identity is SMTP-addressible. As far as I'm concerned, it's <username>@<domain>, with some IP-based way of verifying an assertion of that username. In 99.9% practice, however, this does mean that we're talking about SMTP-addressible IDs. (And I think the 0.1% explains the divergence between what Ben and Dan are saying).

Site developers badly want an SMTP-addressible ID - because they want to reach you - but BrowserID, with full primary (e.g. HTTP-authenticated) identities, makes no assertion about whether a given identity is actually SMTP-addressible or not. That's a design tension that your use cases do a good job pointing out. Again, the protocol just asserts ownership of a username at a domain -- but that's a techie, internal detail, which most users will not fully understand. We could propose a new messaging scheme, which bootstraps from a username@domain identity to (e.g.) an HTTP post queue -- but that would require a bunch of new tech, and SMTP works today.

I believe that there is a definite place for remailer-identity-providers, and that Mozilla should operate one, to address a number of the use cases you describe. In my blog post I lay out a couple ideas for on-demand creation of pseudonymous remailer IDs, from an authenticated primary identity, which would preserve addressibility for site developers while protecting both anonymity and revokability. I think that's a roundabout way of saying that I agree with you that the problem statement need not require a "real" addressible email address - but that developer adoption depends on having some way for a site to reach users, sometimes.

The challenge for an open, distributed identity system is that the leading proprietary identity systems (which are currently winning much of the web) provide stable (and completely correlatable) identities, with proprietary notification schemes (feed, wall, stream, what have you). We do need to match those features to have a compelling product.

-MH

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

[Peter Williams]

The argument made various claims and assertions. Several new and untested approaches were advocated. Nothing that has gone before got the slightest credit (it all failed, or was not even worth a mention).

This all sets a tone.

We have already seen that scope has expanded. Browserid is not a better Openid. Now it's also about custom crypto signaling with mail servers, it wants to liaise with Dnssec, web finger also gets thrown in as do a few host metas. Perhaps XML signed metas are in there too (who knows).

Then there is the matter of Apis, trusted javascript libraries, key escrow (or not), something called ssl and https, and recently centralized control and governance (with a promise to devolve, one day).

It's getting large (and risky). Since it uses nothing from that which is well deployed and multi-vendor, it's all very novel.

One might wish to pare down a bit the scope, and get some wins, so the adoption risks go down. The needs for infrastructure change are too high, as it stands. Remember ipv6; it's hard!

Sent from my iPhone

[Jeff Schnitzer]

On Friday, January 20, 2012 6:33:14 PM UTC-5, Peter Williams wrote:
>
> One might wish to pare down a bit the scope, and get some wins, so the adoption risks go down. The needs for infrastructure change are too high, as it stands. Remember ipv6; it's hard!

+1

As a relying party, what I want is authentication to an email address. Without an email address, I wouldn't even consider BrowserID. I'm much more concerned that BrowserID nails the minor details around this minimum functionality (in particular, changing email addresses) than about all these other complexities that meet various niche needs.

Jeff

[David Illsley]

On 19 Jan 2012, at 15:20, Benjamin Smedberg <benj...@smedbergs.us> wrote:

> <snip>

> Ben Adida said a while back that "relying parties still get an addressable email address" while Dan Mills said "Also note that the verified email spec doesn't assume email addresses are actually SMTP routable." Those statements seem directly at odds with eachother. Which is it?

In a distributed model, even if the spec did assume the addresses are SMTP routable, it wouldn't mean all primaries would live up to this.

> If I decided that I wanted to implement my owner provider that gave identity assertions for som...@anonymous.smedbergs.us with the explicit understanding that these were not meant to be addressable emails... wouldn't most websites (Relying Parties) still need to do their own email verification step in the case where they actually required an addressable email?

Yes... Well... Maybe. It's hopefully a reasonable assumption that you wouldn't use a non-routable address for a site which you want to receive email from. I don't remember the primary UX flow clearly enough, but it's possible your implementation could even ask you that question. The difference between a non SMTP routable address, and a routable one which you only ever check when signing up for junk accounts is in my mind minimal from the site owners perspective. If the user wants to opt out of getting emails from you, there are many ways for that to happen. The trick here then is to lead with BrowserID.org which does provide a routable SMTP address, which sets the norm, which anonymising primary providers will want to engage with (e.g. By providing email forwarding... Wouldn't it be cool to have an identity/forwarding address for each site you use which only accepts email from that domain...)

David

[Benjamin Smedberg]

On 1/19/12 12:31 PM, Mike Hanson wrote:
> You raise many of the problems that bedevil any attempt to create an
> internet-scale identity system. Crafting a system that is memorable,
> fully-distributed, anonymizable, and supports directed (e.g.
> single-identity-per-site) identity tokens is incredibly difficult, and
> has many hard corner cases.
>
> I put my own thoughts on this down in my blog a while back, with the
> first version of the protocol proposal, here:
>
> http://www.open-mike.org/entry/verified-email-protocol
> (the introduction section sets out my thoughts on the problem statement)
>
> You'll note that I, at least, am not particularly wedded to the idea
> that a browserID-asserted identity is SMTP-addressible. As far as I'm
> concerned, it's <username>@<domain>, with some IP-based way of
> verifying an assertion of that username. In 99.9% practice, however,
> this does mean that we're talking about SMTP-addressible IDs. (And I
> think the 0.1% explains the divergence between what Ben and Dan are
> saying).

If identifiers are not SMTP-routable, why are we using the "email"
terminology all over the place? I strongly encourage you to revise both
the name of the spec to "verified identity protocol" and stop using
"email" in the API.

If browserid.org *assumes* that identity==control of email (as it does
today), it seems that you are opening people up to insecurity/phishing
attacks. For example, let's say that I were yahoo mail and I want to
implement an identity provider which uses a hardware login device for
extra security. If somebody trying to hack my users got access to their
email *only once* (perhaps through an internet cafe where the user
forgot to log off), couldn't they get a browserid.org account for
m...@yahoo.com and subsequently bypass all of the extra identification
which my own provider requires?

It seems to me that all identity providers including browserid.org
should be scoped to providing identifiers for a particular domain. So
for example browserid.org ought to provide identities *only* for
@browserid.org. For browserid.org in particular that might take the
form of escape...@browserid.org, so e.g. my identity might be

benj...@40smedbergs.us@browserid.org

This would by default mean that IDs were not SMTP addressable, which
would be a good thing for the protocol overall.

--BDS

[Peter Williams]

I think I can see both the architectural and political subtexts that underly browserid, and I'm not unhopeful. Its at least pushing the envelope (and doesnt look like yet another websso protocol, now in some other bit format). It actually looks like is trying to change the game, and use infrastructure more intelligently. I see Google identity and endpoint management knowhow written all over it (not that this is a bad thing). In my world that is JUST about to adopt what folks produced 5 years ago, Im trying to see how browserid would fit in to that as an evolutionary step. the world of then is based on the traditional email control paradigm. And yes, I understand that browserid is MUCH MORE than merely your typical account provisioning "ping on an email box" to test for liveness and user access. Browserid has a clear cryptographic component, which MTAs as agents themselves are in a continuing security enforcement relationship with IDPs, for account linking. The MTAs themselves are trying into DNS, and then DNSSec for secure zone transfers and SOA. We have a secure name-based cryptographic system, one that will gate access to the crypto-API in browsers (which will make governments happy). So, when one sees the start of the art of todays (identity) mess, discussed http://yorkporc.wordpress.com/2012/01/22/hooking-up-webid-to-yahoo-via-semantic-markup/, I keep trying to see where browserid fits in. For it has to have a story in the world that was discussed in that post. BrowserID has to both update the mess, but also work within it. Its the web, after all, and we must address web culture (for all its messiness).
> Date: Sun, 22 Jan 2012 11:18:51 -0500
> From: benj...@smedbergs.us
> To: mha...@mozilla.com
> Subject: Re: BrowserID problem statement?
> CC: dev-id...@lists.mozilla.org

[Dan Callahan]

Hi Benjamin,

On 1/22/12 10:18 AM, Benjamin Smedberg wrote:
> If somebody trying to hack my users got access to their email *only once* (perhaps through an internet cafe where the user forgot to log off), couldn't they get a browserid.org account for m...@yahoo.com and subsequently bypass all of the extra identification which my own provider requires?

I'm still coming up to speed on BrowserID, but the current system does
indeed act as you described: If you can read an account's email, you can
obtain signed assertions that you control that address from BrowserID.org.

It sounds like you're concerned that you would then have the perpetual
ability to assert yourself as that identity, despite example.com's
two-factor authentication. I don't think that'd work out in practice, since:

1. In your scenario, example.com is a perfectly capable Primary
Authority, and that fact is programatically discoverable.

2. Any cryptographically valid assertion from the browserid.org account
will be emblazoned with the Secondary Authority (browserid.org) that
verified control of the address.

3. Every Relying Party must explicitly elect to trust each Secondary
Authority.

Thus, if I'm a Relying Party, I would look askance at any assertion
signed by a Secondary Authority for us...@example.com.

Similarly, if I'm a Secondary Authority, I would likely be remiss in
issuing new credentials for users at example.com based on an emailed
token, if at all.

> It seems to me that all identity providers including browserid.org
> should be scoped to providing identifiers for a particular domain.

I think that's what the "issuer" field on the assertion is for. Can you
think of corner cases where that wouldn't be sufficient?

> This would by default mean that IDs were not SMTP addressable, which
> would be a good thing for the protocol overall.

I'd really appreciate it if you could go into more detail about why this
would be a good for the protocol. From the standpoints of an RP or a
User, I think emails make a ton of functional and semantic sense, but
there are probably things I'm overlooking. I'd love to hear more.

Thanks,
-Dan

[Dan Mills]

On Sunday, January 22, 2012 at 8:18 AM, Benjamin Smedberg wrote:
> On 1/19/12 12:31 PM, Mike Hanson wrote:
> >
> > You'll note that I, at least, am not particularly wedded to the idea
> > that a browserID-asserted identity is SMTP-addressible. As far as I'm
> > concerned, it's <username>@<domain>, with some IP-based way of
> > verifying an assertion of that username. In 99.9% practice, however,
> > this does mean that we're talking about SMTP-addressible IDs. (And I
> > think the 0.1% explains the divergence between what Ben and Dan are
> > saying).
> >
>
> If identifiers are not SMTP-routable,
>
>

They are today, but they need not be forever.

> why are we using the "email"
> terminology all over the place?
>
>

Because:
* as things stand, it is about email addresses (and email addresses are only smtp routable today). the only way to use BrowserID right now is to use browserid.org as a secondary authority, which works by emailing you to verify ownership. This will change very soon with primary support, but not yet.
* most users and developers understand and want email, generally speaking. it's confusing to most people to talk about hypothetical user...@example.net identifiers which are not smtp routable.

> I strongly encourage you to revise both
> the name of the spec to "verified identity protocol" and stop using
> "email" in the API.
>
>

this is mostly already done, in part because of this reason. The proposed API is now "navigator.id.get()" for example. Most people don't know BrowserID emerged out of VEP, and we will probably drop that name altogether soon.

> If browserid.org (http://browserid.org) *assumes* that identity==control of email (as it does

> today), it seems that you are opening people up to insecurity/phishing
> attacks. For example, let's say that I were yahoo mail and I want to
> implement an identity provider which uses a hardware login device for

> extra security. If somebody trying to hack my users got access to their

> email *only once* (perhaps through an internet cafe where the user

> forgot to log off), couldn't they get a browserid.org (http://browserid.org) account for
> m...@yahoo.com (mailto:m...@yahoo.com) and subsequently bypass all of the extra identification

> which my own provider requires?
>
>

Not if yahoo.com is a primary ID provider. in that case, browserid.org would not use SMTP to confirm ownership of email--this is exactly why SMTP is not required in the future. The flow to get a certificate from a primary and use it on a relying party is SMTP-free, opening up the possibility for email addresses which are not SMTP-routable (though hopefully they are routable in some other way).

> It seems to me that all identity providers including browserid.org (http://browserid.org)
> should be scoped to providing identifiers for a particular domain. So
> for example browserid.org (http://browserid.org) ought to provide identities *only* for
> @browserid.org (http://browserid.org). For browserid.org (http://browserid.org) in particular that might take the
> form of escape...@browserid.org (mailto:escape...@browserid.org), so e.g. my identity might be
>
>


You are talking about what we call a "primary", which we are rolling out support for in the next couple of weeks. browserid.org is a "secondary", meaning an identity provider which is making claims about *other* identifiers. We expect (and want) only a very limited number of these, as secondaries are only useful to bootstrap the system.

> benj...@40smedbergs.us (mailto:benj...@40smedbergs.us)@browserid.org (http://browserid.org)

>
> This would by default mean that IDs were not SMTP addressable, which
> would be a good thing for the protocol overall.
>
>

I think what you mean is "we could make you choose a browserid.org username and give you a browserid.org email" ? Otherwise the destination email is in the string, any web site can trivially get the real email.

We could have made (and still can make) browserid.org a primary, but secondaries are a crucial element in our strategy to bootstrap the system. The majority of sites *do want* a real email address for their users (a stable identifier that users will remember and can also be used to reach them). We are balancing that with the ability to use pseudonyms, potentially trivially, but it is important that the identifiers be email addresses at this stage.

To put it another way: even if we make browserid.org a primary and give you the choice to have an @browserid.org email, we would still make that an SMTP-routable email. Not because it's required by the protocol (it's not), but because not doing so destroys too much of the value prop to the site. Plus, no one would understand why user...@browserid.org isn't reachable via SMTP when it looks like an email address.

Dan

[Benjamin Smedberg]

On 1/22/12 3:54 PM, Dan Mills wrote:
>
>> why are we using the "email"
>> terminology all over the place?
> Because:
> * as things stand, it is about email addresses (and email addresses
> are only smtp routable today). the only way to use BrowserID right now
> is to use browserid.org as a secondary authority, which works by
> emailing you to verify ownership. This will change very soon with
> primary support, but not yet.

> * most users and developers understand and want email, generally
> speaking. it's confusing to most people to talk about hypothetical
> user...@example.net identifiers which are not smtp routable.

Which people, users or developers? Why is it necessary for users to see
these identifiers at all? Wouldn't their browser (or browserid.org) let
them pick from a list, or enter their email address, entirely separately
from the identifier given to a website?
>
>> benj...@40smedbergs.us
>> <mailto:benj...@40smedbergs.us>@browserid.org <http://browserid.org>

>>
>> This would by default mean that IDs were not SMTP addressable, which
>> would be a good thing for the protocol overall.
>
> I think what you mean is "we could make you choose a browserid.org
> username and give you a browserid.org email" ? Otherwise the
> destination email is in the string, any web site can trivially get the
> real email.

No, I mean "we could have you choose a browserid.org username and keep
your existing email".

So I would be eaf12...@browserid.org or
benjamin%40smedb...@browserid.org or whatever. And when I sign in to
a site, the site could request to also receives an assertion that my
routable email address is benj...@smedbergs.us.

> bootstrap the system. The majority of sites *do want* a real email
> address for their users (a stable identifier that users will remember
> and can also be used to reach them). We are balancing that with the
> ability to use pseudonyms, potentially trivially, but it is important
> that the identifiers be email addresses at this stage.

Sure, they want it. But my point is that they aren't getting it! If we
build into the system now that identifiers are roughly synonymous with
email addresses, then websites will send email to identifiers.
Apparently we don't want them to do that (since we don't believe that
they are routable). If having a routable email address is important as a
value proposition and early adoption, then we should make an API
explicitly for doing that. If it's not important, why are we bothering
with the pretense?

--BDS

[Ozten]

On Jan 23, 10:51 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> On 1/22/12 3:54 PM, Dan Mills wrote:
> >> why are we using the "email"
> >> terminology all over the place?
> > Because:
> > * as things stand, it is about email addresses (and email addresses
> > are only smtp routable today). the only way to use BrowserID right now
> > is to use browserid.org as a secondary authority, which works by
> > emailing you to verify ownership. This will change very soon with
> > primary support, but not yet.
> > * most users and developers understand and want email, generally
> > speaking. it's confusing to most people to talk about hypothetical

> > usern...@example.net identifiers which are not smtp routable.

>
> Which people, users or developers? Why is it necessary for users to see

The verified email protocol paves cowpaths:
* Real world users understand an email address
* Many users have multiple email addresses and manage them roughly as
identities
* Web developers build a "verify email flow" into most apps
* Businesses run off email, even if only to bootstrap higher value
identifiers (SSN, phone numbers, etc) and verification

> This would by default mean that IDs were not SMTP addressable, which
> would be a good thing for the protocol overall.

If we use a non-email token and don't present it to the user... how
will inter-op work between User Agents?

A better identifier than email is difficult to find - some of OpenID's
adoption issue can be attributed to a difficult to remember/understand
identifier.

I like VEP's current spec because it's simple (from a web dev's
implementation perspective) and codifies real world behavior.

[Jeff Schnitzer]

On Monday, January 23, 2012 1:51:31 PM UTC-5, Benjamin Smedberg wrote:
> Sure, they want it. But my point is that they aren't getting it! If we
> build into the system now that identifiers are roughly synonymous with
> email addresses, then websites will send email to identifiers.
> Apparently we don't want them to do that (since we don't believe that
> they are routable). If having a routable email address is important as a
> value proposition and early adoption, then we should make an API
> explicitly for doing that. If it's not important, why are we bothering
> with the pretense?

I don't think this ambiguity is an actual problem. Or rather, it's not a new problem.

*All* SMTP identifiers are potentially non-routable. Maybe there is no MTA at that address, maybe the box is full, maybe the user has a filter that dustbins all your email, maybe the box has been abandoned by the user. If you extend the definition of the "network" to be everything between the sender and the eyeball of the intended recipient (the only definition that actually matters), you have to accept that email is by nature a very lossy system. Even if you can verify delivery of one email, you can't guarantee that any further deliveries will work.

99.999% of browserids will successfully route SMTP. The few that won't are most likely ubergeeks who choose to deliberately refuse email, and as a RP there's no practical reason to treat them differently than any other users who configure their MTA to reject email from you. If the ubergeek subsequently decides they actually *do* want to receive mail from you, they can use browserid to change their id/email address to something that works.[1]

It's possible to imagine some future extension to browserid that conveys user preference information (like "don't ever send me email"), but this isn't necessary to make the system useful today.

[1] This is one reason why I'd like to see more focus on the UX of changing an email address, which still feels a little rough IMO.

Jeff

[Benjamin Smedberg]

On 1/24/12 8:51 AM, Shane Tomlinson wrote:
>
>
> Do you want to have an identifier that is hidden from the user?
I think that would be acceptable, yes...
> For a user, is the ideal situation to go to a site, have no idea
> what the identity token is, and just be able to sign in?
Yes. In the current world where browserid.org is the only identity
provider, signing in means popping up a browserid.org window for login.
The user can then sign into browserid.org with their email as they do
today (or if they have already used browserid.org, just pick their
identity from a list). But what the site gets could just as well be
"a3f1...@browserid.org" and not an actual email address.

browserid.org would still need to do email verification in order to do
password reset services and identify users, but that's an implementation
detail specific to browserid.org.

An API for getting a contact email for the user is something that we
*should* provide, but it's no longer directly tied to the identity token.

> Or, do you want the authentication identifier to be distinct from
> the user's "contact me @" identifier?
Yes.
>
> Since most sites require an email address already, what advantages are
> there to creating a new identifier type? Is the new identifier easily
> sharable? Could I share a photo with my family/friends just by saying
> "hey, my account is <x>" and have it easily remembered? That is one
> of the huge advantages to email identifiers, people remember them. If
> I were to have a random letter/number string assigned to me, what are
> the chances of me remembering that?
Why would you need to remember it? The point is that in the current
world browserid.org remembers it for you, and in the future world your
browser remembers it for you. You can recover that information by
logging back into browserid.org at any time.
> Plus, when I share an email address with other people, they understand
> the format. After a while, email addresses become associated with
> people and their personalities.
Except, as noted, for all the situations where I don't have an email
address, or I'm not sure whether I want to disclose it to a particular
website.
>
> The email address in reality is only a small part of a much larger
> identity. If a user has multiple online profiles, a single email
> address could be shared across multiple profiles, and at this point
> the email address is not a unique identifier for a profile, but it is
> still a unique identifier for the user.
>
My point is that people should have the ability to control "providing an
identity for a site to remember data about me" separately from
"providing an email contact point for me". The hoops that people have
proposed (using anonymizing email services) are fine if you're sure that
you don't ever want to provide my email address to a site. But I expect
that the more common scenario just doesn't fit:

* I come to a new site, I have to provide an identity so that it works.
At this point I don't trust the site or want to give it my email
* Later I decide that I want to use the service and so I provide it with
my contact information so that it can email me with updates (or whatever
the site does)

The current design assumes that users either 1) want to be anonymous and
are providing a fake email or 2) can be contacted via the address of
navigator.id.get(). I don't think this is a good assumption to make for
many users who are going to want to actually control their identity and
their contact information separately. And it also means that you could
change email addresses without completely changing your identity; most
people I know have changed their primary email address several times
over the years.

--BDS

[Jeff Schnitzer]

[I previously made postings directly to the Google Group, which may
not have made it through to this list. If that context is missing,
please let me know and I will repost. The mailing list arrangement
here is very confusing. Further comments below.]

On Tue, Jan 24, 2012 at 4:47 PM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
>
> The current design assumes that users either 1) want to be anonymous and are
> providing a fake email or 2) can be contacted via the address of
> navigator.id.get(). I don't think this is a good assumption to make for many
> users who are going to want to actually control their identity and their
> contact information separately. And it also means that you could change
> email addresses without completely changing your identity; most people I
> know have changed their primary email address several times over the years.

I think you may be approaching this from the wrong angle. To be
blunt, end-users are not the "customers" here; BrowserID could induce
orgasm with every login and yet fail unless website builders are
motivated to put it on their websites. To the extent that users love
BrowserID it will help adoption, but let's not forget that the people
BrowserID must ultimately make happy are the people building websites.

I suspect, based on nearly all of my past experience authenticating
with websites, that the number of website builders who are willing to
authenticate without an email address is a small portion of the total.
This is especially true for the multiple-login systems that are
likely to pervade for the foreseeable future; to correlate an account
with FB, Google+, or legacy homebrew systems, BrowserID needs to
provide an email address.

Jeff

[Andrew Sutherland]

On 01/24/2012 01:47 PM, Benjamin Smedberg wrote:
> An API for getting a contact email for the user is something that we
> *should* provide, but it's no longer directly tied to the identity token.

This seems important and advantageous to the user and the site.
Specifically, the ability of the user to provide a pre-whitelisted
e-mail address (foo+R...@example.com or even RAN...@example.com) to a
website that differs from the identity address (f...@example.com) seems
superior to the simple alternatives to allow the user to make sure the
e-mail does not end up in their spam folder.

- The user agent remembers the domain the user is authenticating against
and creates a wildcard whitelist for all mails that appear to be from
that domain (and sub-domains) since it is not clear what e-mail
address(es) would normally be used to contact the user about their
account. This is arguably whitelisting with too broad a brush and may
fail to cover third-party e-mailer services.

- The user agent, in cooperation with their domain, always mints new
per-domain identifiers (foo+RANDOM or RANDOM). This allows whitelisting
but results in the identifier no longer being globally useful, such as
allowing detection of other friends who use the service, etc.


There are obviously more sophisticated possibilities, such as having the
site include an X-VEP-Proof header in the e-mail that includes a
certificate/bearer token, having the site PGP-sign its e-mails with a
key the user-agent stored when issuing the identification, etc. All of
those seem more elegant but harder to have people adopt and use, whereas
being able to provide a specific e-mail address is simple and roughly
equivalent to a bearer token.

Andrew

[Ben Adida]

Jumping into this thread a bit late to make an important point.

>> Do you want to have an identifier that is hidden from the user?
> I think that would be acceptable, yes...

This point above illustrates a strong difference of opinion. Hiding the
identifier from the user would miss a gigantic opportunity: users
already understand that they have different personas based on different
email addresses they have. One for work, one for home, for example.
Users already know that using a work email address to shop at Amazon for
personal items is, in some respects, a bad idea (e.g. when they change
jobs.)

So the argument that we should make email "just another attribute" is,
in my opinion, wrong. It's the same mistake OpenID made, leaving users
with this awful dialog when they log in "do you want to log in to site
A, and do you want to give them your email address?" That's redundant
for a large majority of users, and, if users choose to do the former
without the latter, many web sites simply fail.

We are purposely choosing to have the web site and the user use the same
identifier: an email address. Logging in always works. Sites get an
identifier they already understand. Users deliver an identifier they
already associate with a facet of their online identity. This is a
design feature, not an oversight.

-Ben

[Boris Zbarsky]

On 1/30/12 9:52 AM, Ben Adida wrote:
> This point above illustrates a strong difference of opinion. Hiding the
> identifier from the user would miss a gigantic opportunity: users
> already understand that they have different personas based on different
> email addresses they have.

Adult users. Benjamin was specifically asking how we can make this work
for children, who in many cases _can't_ legally have an email address at
least in the US (at least not without their parents and their mail
provider jumping through some flaming hoops first).

> We are purposely choosing to have the web site and the user use the same
> identifier: an email address.

Which completely breaks down when the user doesn't possess one and has
no way to procure one.

> Users deliver an identifier they
> already associate with a facet of their online identity.

The point is, this is not true of all users.

-Boris

[Boris Zbarsky]

On 1/30/12 11:15 AM, Boris Zbarsky wrote:
> On 1/30/12 9:52 AM, Ben Adida wrote:
>> This point above illustrates a strong difference of opinion. Hiding the
>> identifier from the user would miss a gigantic opportunity: users
>> already understand that they have different personas based on different
>> email addresses they have.
>
> Adult users. Benjamin was specifically asking how we can make this work
> for children, who in many cases _can't_ legally have an email address at
> least in the US (at least not without their parents and their mail
> provider jumping through some flaming hoops first).

Or put another way, the end result of this is that only kids of
tech-savvy parents will be able to log in to sites using BrowserID.
Which likely means that BrowserID won't be able to be adopted by sites
targeted at children, yes? And they will be completely locked out of
any site that _does_ choose to adopt BrowserID?

Maybe we don't want 12-year-olds editing devmo (though I'm not
convinced), but this seems like a strange way to enforce such a
restriction...

-Boris

[David Ascher]

Would it be possible for someone to setup a primary specifically for the
purposes of serving kid identities (and not really setting up an email
service provider)? Something like an eyedee.me with child-specific
policies?

--da

[Boris Zbarsky]

How would that help, if we're building in the expectation that browserid
IDs are SMTP-routable?

-Boris

[Benjamin Smedberg]

On 1/30/2012 9:52 AM, Ben Adida wrote:
>
>
> So the argument that we should make email "just another attribute" is,
> in my opinion, wrong. It's the same mistake OpenID made, leaving users
> with this awful dialog when they log in "do you want to log in to site
> A, and do you want to give them your email address?" That's redundant
> for a large majority of users, and, if users choose to do the former
> without the latter, many web sites simply fail.

Is this anecdotal or is there data on it? What kind of failure is it? I
think it would be a perfectly fine default setting to give sites access
to your email and real name at the same time you give them your name
(presumably most sites want your real name too, no?).

The promise of browserID is that your browser can remember your
identities for you... it can present your identity to you however you
want (including using an email address), and you can do the same thing
at browserid.org to bootstrap the system. That doesn't mean that the
identifier that the relying website receives has to be that email address.

>
> We are purposely choosing to have the web site and the user use the

> same identifier: an email address. Logging in always works. Sites get
> an identifier they already understand. Users deliver an identifier
> they already associate with a facet of their online identity. This is
> a design feature, not an oversight.

That was made abudantly clear. I'm trying to point out that your
design decision has some very unfortunate consequences and I therefore
believe that is is the *wrong* design decision.

--BDS

[Jeff Schnitzer]

As I previously mentioned, websites can never assume that an email
address is SMTP routable. The case of a non-routable address is
fundamentally no different than an address whose box is full or
blocked or simply ignored. While it is hopefully rare, there's nothing
wrong with a non-routable email address.

IANAL, but I do have to work with (or around) COPPA issues. It is not
true that children do not have email addresses, or that the
"difficulty" acquiring one will prevent children from logging into
your site:

1) Parents can create an email address which their kids can use as a login
2) Children can lie about their age to get an email address

I know several ten-year-olds. Invariably they use #2, with their
parent's consent and encouragement. What this says about our society
and the moral lesson reinforced by particular law is out of scope for
this mailing list, but BrowserID certainly does not inhibit children
from logging into your site - at least, no more than COPPA rules do.

The reality is that if you are creating a site with children as a
significant audience, you aren't going to use BrowserID anyways. With
or without an email address, the BrowserID login process is simply not
adequate for COPPA compliance - you need contact information for the
parent too. And BrowserID is not exactly child-friendly, with its
small font and drab colors (don't interpret this as a complaint).

Jeff

[Benjamin Smedberg]

On 1/30/2012 11:24 AM, David Ascher wrote:
> Would it be possible for someone to setup a primary specifically for
> the purposes of serving kid identities (and not really setting up an
> email service provider)? Something like an eyedee.me with
> child-specific policies?

Sure.

But that merely postpones the problem: when my child does eventually get
an email address, how do they inform the sites about it? In the current
system, a site isn't ever going to ask for your email address (the way
they would ask for your profile picture, or mailing address, or other
personal information) because everyone assumes that navigator.id gives
you "the" email address.

When you change email addresses, do you have to create new accounts
everywhere? Do I lose all of my social connections?

--BDS

[Boris Zbarsky]

On 1/30/12 12:40 PM, Jeff Schnitzer wrote:
> As I previously mentioned, websites can never assume that an email
> address is SMTP routable.

Well, sure. But the current setup seems to encourage them to assume
just that.

> IANAL, but I do have to work with (or around) COPPA issues. It is not
> true that children do not have email addresses, or that the
> "difficulty" acquiring one will prevent children from logging into
> your site:
>
> 1) Parents can create an email address which their kids can use as a login

This breaks down if the parents think the child is in fact not old
enough to have email.

> 2) Children can lie about their age to get an email address
>
> I know several ten-year-olds. Invariably they use #2, with their
> parent's consent and encouragement. What this says about our society
> and the moral lesson reinforced by particular law is out of scope for
> this mailing list

Well, sure.

> but BrowserID certainly does not inhibit children
> from logging into your site - at least, no more than COPPA rules do.

What do COPPA rules require for accounts that you don't store any
personal information for, if anything? Seems like any bar above that
that BrowserID raises is in fact getting in the way of children using
BrowserID without at least raising moral issues.

> The reality is that if you are creating a site with children as a
> significant audience, you aren't going to use BrowserID anyways. With
> or without an email address, the BrowserID login process is simply not
> adequate for COPPA compliance - you need contact information for the
> parent too.

Do you need it if you don't have contact information for the child and
don't store personal information about the child?

See, I'm looking at this from the perspective of a parent who would like
to be able to have his 5-year-old use web sites that might want to keep
some state and involve a login to retrieve that state but don't care
_who_ the kid is without getting bogged down in the whole creating an
email (5 is way too young) or lying about age morass.

For a 10-year-old, obviously I'd just create a mail. If he hadn't done
it himself by then. But I'm not talking about 10-year-olds here.

> And BrowserID is not exactly child-friendly, with its
> small font and drab colors (don't interpret this as a complaint).

The current UI is pretty explicitly temporary at best, right? But
still, file bugs!

-Boris

[David Ascher]

On Mon Jan 30 10:38:37 2012, Boris Zbarsky wrote:

> See, I'm looking at this from the perspective of a parent who would
> like to be able to have his 5-year-old use web sites that might want
> to keep some state and involve a login to retrieve that state but
> don't care _who_ the kid is without getting bogged down in the whole
> creating an email (5 is way too young) or lying about age morass.

This feels a bit hypothetical to me -- do you have examples of such a
site, that might help me figure it out. (And in particular, if you're
ok with your 10-year old creating an email, why you wouldn't just
create an email assigned to your 5 year old that only you get to read).

The cynic in me believes that COPPA et al. will kick in regardless of
any technically reasonable between 'information about the child' and
'per-user state', and/or that the scenarios you refer to end up being
such edge cases that they probably would have a weak impact on what
compromises are necessary to make progress.

-da

[Boris Zbarsky]

On 1/30/12 2:02 PM, David Ascher wrote:
> On Mon Jan 30 10:38:37 2012, Boris Zbarsky wrote:
>
>> See, I'm looking at this from the perspective of a parent who would
>> like to be able to have his 5-year-old use web sites that might want
>> to keep some state and involve a login to retrieve that state but
>> don't care _who_ the kid is without getting bogged down in the whole
>> creating an email (5 is way too young) or lying about age morass.
>
> This feels a bit hypothetical to me -- do you have examples of such a
> site, that might help me figure it out.

I'll look around. I came across something like this recently...

> (And in particular, if you're ok
> with your 10-year old creating an email, why you wouldn't just create an
> email assigned to your 5 year old that only you get to read).

Because I don't think it's my place to decide for them what spam they'll
get at that address when they're 10? Because I want them to be able to
get whatever email is "cool" to get at that point without having to
change their identities?

> The cynic in me believes that COPPA et al. will kick in regardless of
> any technically reasonable between 'information about the child' and
> 'per-user state'

That's possible. I'm not a lawyer, much less a COPPA expert. If that's
the case, then BrowserID is DOA for kids unless you go the "lying"
approach, and I should just stop worrying about it, I guess.

> and/or that the scenarios you refer to end up being
> such edge cases that they probably would have a weak impact on what
> compromises are necessary to make progress.

Well, from the point of view of large chunks of our industry "families"
are considered an edge case in general, and "children" even more so.
But if we're going to seriously be talking about identity, then a
7-year-old has just as much of one as your typical 20-something....
What they may lack is just ability to enter into binding agreements,
plus whatever COPPA takes away.

-Boris

[Eric Tully]

Club Penguin and Barbie are two very real and very hot sites for kids
that maintain state - and ask kids to remember a username/password.
While COPA died a few years ago, COPPA is alive and well and is a pain
in the ass for developers like me who need to maintain state on sites
for kids under 13. Exposing an email address is prohibited by COPPA as
the "PP" stands for privacy protection. A browserID solution that would
explicitly NOT deliver the email to the RP would be very useful.

- Eric

On Mon, Jan 30, 2012, at 11:02 AM, David Ascher wrote:
> On Mon Jan 30 10:38:37 2012, Boris Zbarsky wrote:
>

> > See, I'm looking at this from the perspective of a parent who would
> > like to be able to have his 5-year-old use web sites that might want
> > to keep some state and involve a login to retrieve that state but
> > don't care _who_ the kid is without getting bogged down in the whole
> > creating an email (5 is way too young) or lying about age morass.
>

> This feels a bit hypothetical to me -- do you have examples of such a

> site, that might help me figure it out. (And in particular, if you're

> ok with your 10-year old creating an email, why you wouldn't just
> create an email assigned to your 5 year old that only you get to read).
>

> The cynic in me believes that COPPA et al. will kick in regardless of
> any technically reasonable between 'information about the child' and

> 'per-user state', and/or that the scenarios you refer to end up being

> such edge cases that they probably would have a weak impact on what
> compromises are necessary to make progress.
>

> -da

[David Ascher]

On Jan 30 '12 11:13 AM, Boris Zbarsky wrote:
> Because I don't think it's my place to decide for them what spam
> they'll get at that address when they're 10?

They wouldn't, you will. ;-)

> Because I want them to be able to get whatever email is "cool" to
> get at that point without having to change their identities?

My take is that as a parent of a young child I'm making lots of
decisions for them, starting with their name. As they grow up, they get
to decide which of those decisions they like and which ones they don't,
and they can figure out the tradeoffs in all of those cases.

> That's possible. I'm not a lawyer, much less a COPPA expert. If
> that's the case, then BrowserID is DOA for kids unless you go the
> "lying" approach, and I should just stop worrying about it, I guess.

I think 'interoperable generic identity systems on the internet for
kids' is a DOA concept -- the entire premise of COPPA I expect is that
kids shouldn't be full participants on the internet. =)

To respond to Eric's point --

It feels like it would be possible for a site like ClubPenguin to
require email addresses from the parents (as they do today), and then
issue identities to their children (as they do today), and use BrowserID
as the protocol to let both parents and children sign in (with different
resulting permissions). The question then becomes whether it'd be
possible for ClubPenguin-using kids to use their CP identity to sign in
to other sites? If CP didn't want them to, then they could just send
the verifying emails to dev/null.

IOW, an IdP could choose to only be valid for its own domain, and not
support SMTP, right?

--da

[Boris Zbarsky]

On 1/30/12 2:28 PM, David Ascher wrote:
> On Jan 30 '12 11:13 AM, Boris Zbarsky wrote:
>> Because I don't think it's my place to decide for them what spam
>> they'll get at that address when they're 10?
>
> They wouldn't, you will. ;-)

Until they get that address as "their identity", yes?

>> Because I want them to be able to get whatever email is "cool" to get
>> at that point without having to change their identities?
>
> My take is that as a parent of a young child I'm making lots of
> decisions for them, starting with their name. As they grow up, they get
> to decide which of those decisions they like and which ones they don't,
> and they can figure out the tradeoffs in all of those cases.

Yes. And this is a decision that I don't think I should be making for
them if it's not required. Obviously, if I have to I have to and I'll
just do it. But it seems like we're just saying "ok, who cares about
the 10-year-olds; we'll make their life harder so we can make our life
easier in these other ways".

> I think 'interoperable generic identity systems on the internet for
> kids' is a DOA concept -- the entire premise of COPPA I expect is that
> kids shouldn't be full participants on the internet. =)

It doesn't so much matter what the "premise" is. What matters is what
the law actually requires.

-Boris

[Boris Zbarsky]

On 1/30/12 2:33 PM, Boris Zbarsky wrote:
> But it seems like we're just saying "ok, who cares about the
> 10-year-olds; we'll make their life harder so we can make our life
> easier in these other ways".

And yes, my viewpoint can best be summarized as "Think of the children!" ;)

-Boris

[Jeff Schnitzer]

(I suspect this was a reply-all failure)

It is interesting that your legal department thinks you can avoid the
parental notification requirements simply by not storing any of the
'usual' fields. It may very well be true.

You can easily accomodate this requirement by storing a one-way
encrypted version of the email address that browserid gives you.

Jeff

On Mon, Jan 30, 2012 at 3:26 PM, Eric Tully <er...@tully.com> wrote:
>
>
>> On Mon, Jan 30, 2012 at 2:23 PM, Eric Tully <er...@tully.com> wrote:
>> >    <snip>   A browserID solution that would

>> > explicitly NOT deliver the email to the RP would be very useful.
>>

>> Can you explain how not having the email can help the RP?
>>
>
>
>
> Forgive me.  My experience with COPPA consisted of our possibly
> incorrect lawyers giving me development guidelines.  Therefore I may or
> may not know what
> I'm talking about.  Their specific instruction to me was this:  If we
> don't ask for an email AND we have no personally identifying info THEN
> we don't even have to ask how old they are and we can end run around
> COPPA altogether.  My comment to this this BrowserID discussion was
> strictly in response to the question, "This seems hypothetical, can you
> give specific examples of sites..."
>
>
>
>>
>> Exposing an email address to the public is a big no-no whether your
>> user is a child or an adult.  This doesn't change anything.
>>
>
>
> Agreed 100%, big no-no either way.  I said "NOT deliver the email to the
> RP" and was only referring to that scenario and didn't mean expose to
> the public.  If BrowserID told me, the RP, "As far as you're concerned,
> this is user number 12345, we can assure you of that much and we're
> definitely not going to tell you his email address.  Any visitor
> tomorrow with user number 12345 is the same guy, we promise.  Note that
> this same user has a different user number at any other RP so don't try
> to correlate with other sites",  that would be a useful tool for me
> because I can maintain state for kids under 13 and I don't have to think
> about COPPA because I can prove that I can't identify the kid (which was
> the deciding issue as far as MY lawyer was concerned, remember).
>
>
>
>> There is one interesting potential case which is that if browserid.org
>> records the age of a user, then theoretically *it* comes under COPPA
>> rules if the age is less than 13.  But this has nothing to do with the
>> email vs id debate.
>
>
>
> IANAL so I can only wonder if BrowserID/Mozilla has to adhere to COPPA
> laws if they DON'T store / track ANY data such as how many times the
> user visited an RP's site or which sites they logged into (which I'm
> pretty sure Mozilla won't do).  That is, they do have personally
> identifying info but DON'T keep any data beyond that.
>
>
>
> - Eric

[Dan Mills]

I'll preface by saying that I don't think kids under 13 are or should be a primary demographic for BrowserID. We have decided (as a society) to treat them specially, and that's OK, it also means that the same ID technology we use for 13+ might not be appropriate for them.

That said, there are circumstances where BrowserID could work for a kids' site. I did some quick research by going to a few sites and I found a mixture of:

* Content available without any personalization, or using only temporary session tracking via cookie or equivalent (e.g., PBS Kids)
* Accounts based on the *parent's* email (e.g., Disney)
* Accounts without email, username/password based (e.g., nick.com)

Clearly BrowserID could work for the email-based account, at the very least as a way to bootstrap account creation / enable recovery. Jeff's idea to store only a hashed version of the email is also a possibility that might work in some cases (I don't know).

Finally, BrowserID does *not* mandate that email address disclosed to the RP be your "primary" address or anything of the sort. You can already (manually) add pseudonyms today, and particularly with primary support there is a smooth path to disclosing a brand new pseudonym any time you wish to. If we really want to it is even possible (protocol-wise) for the user agent to automatically negotiate the creation of a new pseudonym, at which point we're just arguing about identifier syntax.

Dan

On Monday, January 30, 2012 at 9:38 AM, Benjamin Smedberg wrote:

> On 1/30/2012 9:52 AM, Ben Adida wrote:
> >
> >
> > So the argument that we should make email "just another attribute" is,
> > in my opinion, wrong. It's the same mistake OpenID made, leaving users
> > with this awful dialog when they log in "do you want to log in to site
> > A, and do you want to give them your email address?" That's redundant
> > for a large majority of users, and, if users choose to do the former
> > without the latter, many web sites simply fail.
> >
>
> Is this anecdotal or is there data on it? What kind of failure is it? I
> think it would be a perfectly fine default setting to give sites access
> to your email and real name at the same time you give them your name
> (presumably most sites want your real name too, no?).
>
> The promise of browserID is that your browser can remember your
> identities for you... it can present your identity to you however you
> want (including using an email address), and you can do the same thing

> at browserid.org (http://browserid.org) to bootstrap the system. That doesn't mean that the

> identifier that the relying website receives has to be that email address.
>
> >
> > We are purposely choosing to have the web site and the user use the
> > same identifier: an email address. Logging in always works. Sites get
> > an identifier they already understand. Users deliver an identifier
> > they already associate with a facet of their online identity. This is
> > a design feature, not an oversight.
> >
>
> That was made abudantly clear. I'm trying to point out that your
> design decision has some very unfortunate consequences and I therefore
> believe that is is the *wrong* design decision.
>
> --BDS
>

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

[Ben Adida]

On 1/30/12 9:38 AM, Benjamin Smedberg wrote:
> Is this anecdotal or is there data on it?

I don't think we have an actual study (though Dan and MikeHanson might
know of one), but we certainly have a significant amount of anecdotal
evidence. Look at most of the web sites you use. For the most part, they
require an email address. Look at most of the OpenID transactions: they
all ask for an email address and when they fail, they end up prompting
you for an email address if they don't get one from your IdP. (That's a
pretty awful UX failure.)

> The promise of browserID is that your browser can remember your
> identities for you.

That's not quite complete in a crucial way. We want BrowserID to let
your user-agent *negotiate* the identity transaction with web sites.
That means you have to take into account what the web sites wants/needs.
If you provide none of what they need, then the outcome is obvious: the
solution won't get used.

Web sites need a way to identify you uniquely in a decentralized way,
and they need to be able to contact you. And we want the user to
understand the transaction they're agreeing to. That's why we use email
addresses: 3 reasons, not 1.

> That was made abudantly clear. I'm trying to point out that your design
> decision has some very unfortunate consequences and I therefore believe
> that is is the *wrong* design decision.

So far, the only consequence I see is that we don't yet have a full
solution for users under 13. That's certainly worth an exploration, and
I think Dan has some good ideas, but I don't think we can structure a
good solution around that premise. (You're not legally allowed to use
most online services like Google, Twitter, and Facebook until you're 13.)

If you actually think we're making a *wrong* decision, then I suspect
this means we might have to agree to disagree.

-Ben

[Shane Tomlinson]

For anybody else that is as ignorant about the details of this law as I
am, here is it's text - http://www.coppa.org/coppa.htm

Shane

On 1/30/12 7:23 PM, Eric Tully wrote:
> Club Penguin and Barbie are two very real and very hot sites for kids
> that maintain state - and ask kids to remember a username/password.
> While COPA died a few years ago, COPPA is alive and well and is a pain
> in the ass for developers like me who need to maintain state on sites
> for kids under 13. Exposing an email address is prohibited by COPPA as

> the "PP" stands for privacy protection. A browserID solution that would

> explicitly NOT deliver the email to the RP would be very useful.
>

> - Eric
>

[Shane Tomlinson]

On 1/30/12 7:13 PM, Boris Zbarsky wrote:
>> The cynic in me believes that COPPA et al. will kick in regardless of
>> any technically reasonable between 'information about the child' and
>> 'per-user state'
>
> That's possible. I'm not a lawyer, much less a COPPA expert. If
> that's the case, then BrowserID is DOA for kids unless you go the
> "lying" approach, and I should just stop worrying about it, I guess.

I'm not a lawyer either, but reading over the text it does seem
relatively clear that if BrowserID asks for personal information - and I
would suppose an email address (whether obtained legitimately or not) is
included - we have to disclose which information we are collecting and
we have to "obtain verifiable parental consent for the collection, use,
or disclosure of personal information from children." (sections 1303 b1
Ai and 1303 b1 Aii)

Whether BrowserID can disclose that information to other sites with
parental consent is another question entirely. Can the legal department
give us some guidance?

Shane

[Ben Adida]

On 2/1/12 3:38 AM, Shane Tomlinson wrote:
> I'm not a lawyer either, but reading over the text it does seem
> relatively clear that if BrowserID asks for personal information - and I
> would suppose an email address (whether obtained legitimately or not) is
> included - we have to disclose which information we are collecting and
> we have to "obtain verifiable parental consent for the collection, use,
> or disclosure of personal information from children." (sections 1303 b1
> Ai and 1303 b1 Aii)
>
> Whether BrowserID can disclose that information to other sites with
> parental consent is another question entirely. Can the legal department
> give us some guidance?

Note that the general approach that sites take, like Facebook, is to say
"we don't allow kids under 13." Sadly, that's the only way to do it,
because how can you possibly get "parental consent?"

I'll start a thread with legal to look into this, but I don't think we
can make this a high priority given how other sites have been forced to
punt, in large part because of this law.

-Ben