Getting an email via AJAX

[Melvin Carvalho]

Sorry if this has come up before, I did try searching for the answer.

Can I get the (verified) email using AJAX or some other js

navigator.id.get(function(assertion) {
if (assertion) {

//**** Get Email Address **** <------

} else {
// something went wrong! the user isn't logged in.
}

[Eric Tully]

Melvin,

I had trouble with that too and I can't really imagine why it
should matter. After spending an hour on it, I sent the assertion up to
my own server and initiated the call to https://browserid.org/verify
from a PHP script via Curl and it worked just fine. I figure it's
either that their server doesn't like the User-Agent coming from an Ajax
call or that they are sending a Status-Code that Ajax isn't prepared for.

- Eric

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

[Melvin Carvalho]

On 27 January 2012 18:04, Eric Tully <er...@tully.com> wrote:
> Melvin,
>
>    I had trouble with that too and I can't really imagine why it should
> matter.  After spending an hour on it, I sent the assertion up to my own
> server and initiated the call to https://browserid.org/verify from a PHP
> script via Curl and it worked just fine.  I figure it's either that their
> server doesn't like the User-Agent coming from an Ajax call or that they are
> sending a Status-Code that Ajax isn't prepared for.

Could the shim perhaps provide the email address, along with the
assertion as a 2nd parameter?

[Eric Tully]

By shim, I assume you are referring to my server side PHP acting as a
relay to browserid's verification server? If so, then yes, the PHP can
return whatever you want back to the client side. This is how my flow
works:

User clicks BrowserID link and logs in
Assertion is passed to my JS callback function.
My JS function uses Ajax, passes assertion to PHP script on my server.
PHP script passes assertion and audience to browserid.org via curl.
browserid.org returns: status, email, audience, expires and issuer.
PHP can respond to the client with any or all of those fields.

So yes, the whole thing takes about a second and feels nice and Ajaxy
and the email can get delivered to the client side if you need that.

If, by shim, you mean the initial response passed to the JS callback
function, lazy programmers would be inclined to ignore the validation of
the assertion and then it would be trivial for people to pose as any
email address they liked (and BrowserID would get incorrectly labeled
insecure). I can't speak for the BrowserID developers but I think that
would be a bad design.

[Lloyd Hilaiel]

On Jan 27, 2012, at 9:34 AM, Melvin Carvalho wrote:

> Sorry if this has come up before, I did try searching for the answer.
>
> Can I get the (verified) email using AJAX or some other js
>
> navigator.id.get(function(assertion) {
> if (assertion) {
>
> //**** Get Email Address **** <------

Hi Melvin,

It's possible to extract the contents of the assertion (including email address),
at this point in code. We have not made it easy because there was some concern
that it would be too easy to trust an assertion before you've verified that it's
valid.

So there are some important caveats, until you've verified the assertion you should not
trust that its valid (and the user actually owns that email)... And while there are no
concrete planned changes to assertion format, I expect discussion as we roll out
primary support and it's possible...

So you could decode the assertion and extract the email
var contents = new Buffer(assertion.split('~')[0].split('.')[1], 'base64').toString();
var email = JSON.parse(contents).principal.email;

(final caveat, that won't work in a browser, you'd have to use window.btoa() to base64
decode).

lloyd

[Melvin Carvalho]

On 27 January 2012 19:55, Lloyd Hilaiel <ll...@hilaiel.com> wrote:
> On Jan 27, 2012, at 9:34 AM, Melvin Carvalho wrote:
>
>> Sorry if this has come up before, I did try searching for the answer.
>>
>> Can I get the (verified) email using AJAX or some other js
>>
>>    navigator.id.get(function(assertion) {
>>      if (assertion) {
>>
>>      //**** Get Email Address **** <------
>
> Hi Melvin,
>
> It's possible to extract the contents of the assertion (including email address),
> at this point in code.  We have not made it easy because there was some concern
> that it would be too easy to trust an assertion before you've verified that it's
> valid.
>
> So there are some important caveats, until you've verified the assertion you should not
> trust that its valid (and the user actually owns that email)...  And while there are no
> concrete planned changes to assertion format, I expect discussion as we roll out
> primary support and it's possible...
>
> So you could decode the assertion and extract the email
> var contents = new Buffer(assertion.split('~')[0].split('.')[1], 'base64').toString();
> var email = JSON.parse(contents).principal.email;
>
> (final caveat, that won't work in a browser, you'd have to use window.btoa() to base64
> decode).

Thanks so much, I'll play around with this.

I know that absence of proof, is not proof of absence, but I'm
struggling at this point, to see what possible harm there could be in
exposing the identity to the browser. :)

[Peter Williams]

If Im understand the core semantic of browserid, we need to change the terminology. Its irrelevant whether the communiation channel over which the datum is signalled in a native browser plugin or an ajax popup. Its elementary assertion theory. As it stands from the marketing and specs, the RP is going to believe it can send a ping email to "verified email address". I think we are are learning that said email address is in fact not an RFC822 name, and does not address an email mailbox. Or at least, it cannot be assumed to have such properties given only the IDP's assertion. NOone is attesting to the value being a live communication service, with mailbox/message-store protocol ports. NOw if Im wrong on this, please make it clearer. Im belaboring the point, to force clarity and get away from model-grade specs:- If nothing else, we need in technical documentation to be be-laboring the point that the identity field registered at the IDP and released to authorized RP sites is a "non-routable value". It just happens to have some visual similarities to RFC822 names, much like I type hom...@msn.com as my userd at Google's home page IDPs to authenticate myself to the half million IDPs it hosts for Google Apps world. Its not that there is ANY attestation by the IDP that there is a live communication service attached to that value were one to treat it as an RFC822name / mailbox address. Google is not saying to the world that hom...@msn.msn is currently a live mailbox. For example, if an RP wants to set terms and conditions on all communications between it and a IDP subscriber, it cannot claim that it sent "privacy policy" notices "via email" to the subscriber, given the identifier being asserted. BY definition, there is no assurance that any such email channel exists, and if it does its unassured. It is not an (IDP vouched for) trustworthy address for communication serices, over which one might build legal protocols imposing such as notices and terms negotiations. At the point when IDPs start issuing the policy statements, they will ve declaring that the identifier is "non-verified subscriber information" - to ensure that no legal representation of accuracy is intended, or that there are "authentication or control" properties not actually present. Yes the IDP, like the CA before it, will be covering its ass - so its not accused of mis-representation and be made unduly liable for claims of false reliance. > Date: Fri, 27 Jan 2012 18:23:19 +0100
> Subject: Re: Getting an email via AJAX
> From: melvinc...@gmail.com
> To: er...@tully.com
> CC: dev-id...@lists.mozilla.org

>
> On 27 January 2012 18:04, Eric Tully <er...@tully.com> wrote:
> > Melvin,
> >
> > I had trouble with that too and I can't really imagine why it should
> > matter. After spending an hour on it, I sent the assertion up to my own
> > server and initiated the call to https://browserid.org/verify from a PHP
> > script via Curl and it worked just fine. I figure it's either that their
> > server doesn't like the User-Agent coming from an Ajax call or that they are
> > sending a Status-Code that Ajax isn't prepared for.
>
> Could the shim perhaps provide the email address, along with the
> assertion as a 2nd parameter?
>
> >
> > - Eric
> >
> >
> >
> >

> > Melvin Carvalho wrote:
> >>
> >> Sorry if this has come up before, I did try searching for the answer.
> >>
> >> Can I get the (verified) email using AJAX or some other js
> >>
> >> navigator.id.get(function(assertion) {
> >> if (assertion) {
> >>
> >> //**** Get Email Address **** <------
> >>

[Jeff Schnitzer]

As per https://groups.google.com/d/msg/mozilla.dev.identity/q3bRhd0Kwaw/irT6Y-kypGUJ,
I don't think there's any requirement for the IdP to provide
additional information about the routability of an address:

* Should an IdP convey that the user's mailbox is full and can't receive mail?
* Should an IdP convey that your IP address block has been
blacklisted from email?
* Should an IdP convey that the user's inbox has 5 billion unread
items and your mail will never be seen?

If you're building a website that sends mail, you need to catch bounce
messages and monitor deliverability anyways. As a RP, I don't see why
a deliberately non-routable email address should be handled any
differently.

Perhaps what you want is an indication from the IdP whether the user
prefers not to have email sent to that address. This seems reasonable
reasonable, although I'm not sure any RP (including myself) would
actually honor it due to the (seemingly high) probability that users
will simply have it turned off by default without thinking. If a user
makes a purchase on my website, I send them a receipt by email...
period. Most receive it.

Jeff

[Peter Williams]

One may have noticed that I have email interworking problems. Hotmail for me & a half billion other users is, these days, just crap about formatting emails (when working with mailing lists). Either I send paragraphs with no CRLFs (if I am in rich text mode), or (if I turn to plaintext mode) the replyTo email is one giant paragraph. Id love to discard it (despite 15+ years of loyalty), and use gmail. But, my MSN/hotmail email id is now tied to at least 10 RP sites, and more than one IDP. hom...@msn.com is now part of my persona - after so many years of use. Its part of my reputation (good or bad you decide). The fact that noone has been provisioned an msn.com email address for the last 10 years is irrelevant.



Hmm. This sound a bit like a pertinent topic for browserid, no? changing email idenifiers, or maintaining multiple thereof?



NOw, using Google IDP builtin to its home page today, I regularly assert to many sites. SOme consume the assertion directly, others are bridged to Google and the bridges does assertion format conversion (to some or other websso standard, from the large collection of them). It asserts a PPID to the RP (not the email account/mailbox id). IN some flows, it attaches the email attribute. When it is presented (as an attribute) this allows the RP nominally to "send PDF signed receipts" etc, as is quite natural.



Of course, browserid is appearing to say that the "receipt sending" feature is a function of the 1 and only 1 value that MUST be delivered to the RP. Whether or not any other profile'd attribute is released is irrelevant (browerid appears to say): the PPID will have RFC822 address form. It *may* route to a message store (mailbox); or may not. The IDP is certainly not saying it will (I think). But then, when Google release an email AX attribute in its openid IDP neither does it say that the email name will route, either. Its a "here is a good hint" - that probably works)



Now, have I got the model correct?



What matters is when a relying party "relies upon" the email'routing property. If the RP believes that it can fulfill its perhaps-legal obligation to give a receipt by posting off an attachment to the mailbox assumed tied to the 1 and only 1 asserted datum, it's going to be unhappy if it doesnt work. Perhaps, it just failed a legal obligation (and made false reliance on an IDP-delivered assurance, to whose issuer its lawyers will surely now go a calling). ALternatively, if there is doubt *but browserid does get the RP mostly happy", it's going then to present a dialog saying: "IDP SUBSCRIBER! do confirm that hom...@msn.com (taken from the PPID field in the assertion) is a live communication service, to which I can - till further notice - send legal notices" (like receipts).






























> Date: Mon, 30 Jan 2012 13:01:34 -0500
> Subject: Re: non routable identifiers having pseudo RFC 822 name form RE: Getting an email via AJAX
> From: je...@infohazard.org
> To: hom...@msn.com
> CC: dev-id...@lists.mozilla.org

[Jeff Schnitzer]

On Mon, Jan 30, 2012 at 1:27 PM, Peter Williams <hom...@msn.com> wrote:
>
> What matters is when a relying party "relies upon" the email'routing property. If the RP believes that it can fulfill its perhaps-legal obligation to give a receipt by posting off an attachment to the mailbox assumed tied to the 1 and only 1 asserted datum, it's going to be unhappy if it doesnt work. Perhaps, it just failed a legal obligation (and made false reliance on an IDP-delivered assurance, to whose issuer its lawyers will surely now go a calling). ALternatively, if there is doubt *but browserid does get the RP mostly happy", it's going then to present a dialog saying: "IDP SUBSCRIBER! do confirm that hom...@msn.com (taken from the PPID field in the assertion) is a live communication service, to which I can - till further notice - send legal notices" (like receipts).
>
>

I have to admit that I didn't follow most of that. And, of course, I
don't speak in any way for Mozilla; I'm just a RP here hoping to
influence the evolution of a tool I use.

What puzzles me is this notion of a "legal obligation". Can you give
me a specific real-world example of where a RP is legally required to
deliver an email to a recipient? And in which the mere act of pushing
"send" in Outlook somehow satisfies this requirement in the absence of
any kind of delivery notice?

If some websites have delivery requirements like this, they must be
rare, specialized things, and it seems that whatever specialized
handshake they need is probably outside the scope of BrowserID.

Jeff

[Ben Adida]

On 1/27/12 11:10 AM, Melvin Carvalho wrote:
> I know that absence of proof, is not proof of absence, but I'm
> struggling at this point, to see what possible harm there could be in
> exposing the identity to the browser. :)

The key point is this: if you parse the assertion in the browser and
extract the email address, and then you make *any* trust decisions based
on this, you're opening yourself up for a world of hurt. A simple
Greasemonkey script would be enough for an attacker to authenticate as
anyone they like.

That's why we try to steer developers far away from this very risky
direction. You can imagine this happening to even very good developers
as follows:

- you extract the email in client-side JavaScript, and you only use it
for display. No problem.

- 3 months later, you've forgotten all about this, you notice you have
the email address in JavaScript, and you use it in a way that actually
requires that you trust it. Boom.

So, I would still recommend that you send the assertion to the server,
verify it there, and return the email address to your JavaScript.

-Ben

[Jeff Schnitzer]

On Tue, Jan 31, 2012 at 2:01 AM, Ben Adida <b...@adida.net> wrote:
>
> So, I would still recommend that you send the assertion to the server,
> verify it there, and return the email address to your JavaScript.

FWIW, Facebook's javascript SDK has a similar login mechanism which
exposes not only the relevant userid but also the full power of the
API in the client, and (as far as I know) this mistake has not been a
common issue. People who are serious about writing server apps know
they should never trust anything the client hands them.

That said, there's at least one prominent developer at Facebook who
Doesn't Get It and consequently getting a verified user id on the
server is actually a little tricky unless you're using the PHP sdk.
Sigh.

Jeff

[Melvin Carvalho]

On 31 January 2012 08:01, Ben Adida <b...@adida.net> wrote:
> On 1/27/12 11:10 AM, Melvin Carvalho wrote:
>>
>> I know that absence of proof, is not proof of absence, but I'm
>> struggling at this point, to see what possible harm there could be in
>> exposing the identity to the browser. :)
>
>
> The key point is this: if you parse the assertion in the browser and extract
> the email address, and then you make *any* trust decisions based on this,
> you're opening yourself up for a world of hurt. A simple Greasemonkey script
> would be enough for an attacker to authenticate as anyone they like.
>
> That's why we try to steer developers far away from this very risky
> direction. You can imagine this happening to even very good developers as
> follows:
>
> - you extract the email in client-side JavaScript, and you only use it for
> display. No problem.
>
> - 3 months later, you've forgotten all about this, you notice you have the
> email address in JavaScript, and you use it in a way that actually requires
> that you trust it. Boom.
>

> So, I would still recommend that you send the assertion to the server,
> verify it there, and return the email address to your JavaScript.

Thanks that's a great explanation.

However, I would suggest that identification, authentication and
authorization are slightly different problems. Using the wrong tool
for he wrong job, as you say, is very dangerous.

But looking at the real world there are sometimes cases where people
can identify and without necessarily authenticate. Imagine I am at a
conference an see someone with a name badge and an institution. I
could authenticate that before speaking to them, but that may be a
pain. Or I could talk to them and if I wanted to do something more
serious, authenticate later. Perhaps this is not the greatest analogy
but hopefully illustrates a point. Projects such as wikipedia have
proved that a little trust can sometimes go a long way, but that's no
excuse for lax security measures.

>
> -Ben

[Ben Adida]

On 1/30/12 11:20 PM, Jeff Schnitzer wrote:
> FWIW, Facebook's javascript SDK has a similar login mechanism which
> exposes not only the relevant userid but also the full power of the
> API in the client, and (as far as I know) this mistake has not been a
> common issue. People who are serious about writing server apps know
> they should never trust anything the client hands them.

Thanks Jeff, that's an interesting datapoint. I wonder if part of this
is mitigated by the fact that Facebook encourages the use of social
plugins, where the security depends less on you and more on them. But
still, good to know.

On the flip side, we have seen a number of people ask why they can't
just do the *verification* in the browser, which tells me that this
isn't obvious to all developers. (That's not the case for this thread.)

My take on this is to be particularly conservative when it comes to
security, especially when it doesn't impact what a developer can do all
that much. In this case, since you can get the user's email by doing the
server-side verification (which is fairly easy), I *think* we're getting
only a tiny bit of pain in exchange for preventing some potentially very
painful mistakes.

-Ben

[Ben Adida]

On 1/31/12 12:36 AM, Melvin Carvalho wrote:
> However, I would suggest that identification, authentication and
> authorization are slightly different problems. Using the wrong tool
> for he wrong job, as you say, is very dangerous.

You're right, these are different problems, and I fully agree that some
sites don't need to do the actual verification.

Since you understand the problem, you can tease apart the two notions of
authentication and identification. So you're very likely to do the right
thing. But, if we exposed an easy client API, then folks who don't have
the time to really investigate this problem would likely use it incorrectly.

Our belief in designing this API is that it should be secure by default,
because we're providing a secure authentication solution. I admit that
this means that some cases that are less about authentication and more
about identification, like yours, may require a bit more work. I think
that's a tradeoff we have to make if we want to ensure that there's no
easy way to shoot yourself in the foot.

By the way, if you don't want to deal directly with the assertion text,
you can use the jwcrypto library (https://github.com/mozilla/jwcrypto)
with a subset of code from:

https://github.com/mozilla/jwcrypto/blob/master/bin/check-assertion

(That's node.js JavaScript, but with the bundled vepbundle.js, you can
use it in the browser.)

-Ben