User: Password:
|
|
Subscribe / Log in / New account

Mozilla "Persona" beta release

Mozilla "Persona" beta release

Posted Sep 28, 2012 8:54 UTC (Fri) by alankila (guest, #47141)
Parent article: Mozilla "Persona" beta release

I know it's just a beta, but here's some criticism anyway about the lack of software maturity and what would likely be showstoppers for roll-out of this technology.

1. It's thin on detail about how it actually works. For instance, it's supposed to send an email. Based on the best documentation available (which is the JS file) there's appears to be a mozilla web service involved here which does this. How are browsers going to be able to send an email in the future, when this feature supposedly becomes integrated in the browser and the need for a JS library goes away?

2. You aren't supposed to include the provided javascript library in your project, but to depend on external mozilla site, because the library might still change. External dependency like that would be unacceptable, as nobody wants to explain to their customer that they can't log in anymore because Mozilla changed something in the JS file.

3. The identity assertions are validated by mozilla's web service. I could find no information about these assertions, or how to validate them yourself. But I did find multiple pages advertising a web service capable of doing this. I'm sure this part will also be documented eventually.

IMHO there should be specification first before a prototype. (If there is a specification, why isn't it linked prominently so that I could find it.) And as to #1, I guess the solution is that website authors expose some URL which sends emails to any given email address. Sounds like spambots are going to like this.


(Log in to post comments)

Mozilla "Persona" beta release

Posted Sep 28, 2012 15:17 UTC (Fri) by JohnLenz (subscriber, #42089) [Link]

You could try this document I don't know about 2 or 3, but the way 1 is supposed to eventually work is no email is ever sent. Instead, your email provider supports the API directly. For example, if gmail could be convinced to support this like they do OpenID, they would provide a url at https://gmail.com/.well-known/browserid which would return some JSON. The browser then creates an IFRAME and points it to a page at gmail.com where gmail.com can check the identity. The authentication using mozilla's servers is there for email providers which don't support this yet, but you can skip mozilla's servers and run the authentication on your own server (which as you say would involve sending email).

Mozilla "Persona" beta release

Posted Sep 28, 2012 22:45 UTC (Fri) by k8to (subscriber, #15413) [Link]

So in order for this to work, I need to support this protocol myself, since I'm my own email provider?

From this, why is a mail provider involved? I'm self-attesting either way.

Mozilla "Persona" beta release

Posted Sep 28, 2012 22:55 UTC (Fri) by ewan (subscriber, #5533) [Link]

"From this, why is a mail provider involved? I'm self-attesting either way"

I haven't read the spec at all, but completely off the top of my head, I'd have thought the point would be to use your email address as a unique identifier (as many sites do now), and provide a way to prove that the browser trying to log into my website belongs to the same person as the email address. You can 'self attest' and that's fine - the point would surely be that I cannot pretend to be you. Of course, you could make your mail server pretend that I'm you, so I could impersonate you with your permission, but that's true of most authentication - if you have a password, you can tell me what it is.

Mozilla "Persona" beta release

Posted Sep 28, 2012 23:58 UTC (Fri) by thedevil (guest, #32913) [Link]

This would never work for me the way I am set up.

I control my email address, but not the web server at the domain (all the mail gets forwarded with procmail).

Mozilla "Persona" beta release

Posted Sep 29, 2012 21:46 UTC (Sat) by geofft (subscriber, #59789) [Link]

What's your setup? All it requires is being able to put a single file inside /.well-known/, or have whoever's running the web server at your domain do that. If you can't do that, I'd argue you don't in fact control the domain. (If they're sending stuff to you via procmail, they can intercept it at any point...)

Mozilla "Persona" beta release

Posted Sep 29, 2012 4:19 UTC (Sat) by k8to (subscriber, #15413) [Link]

But I can pretend to be anyone at my domain (there are several).

Mozilla "Persona" beta release

Posted Sep 30, 2012 2:48 UTC (Sun) by geofft (subscriber, #59789) [Link]

If you own the domain, then yeah, that's true; that's what owning the domain means.

Mozilla "Persona" beta release

Posted Sep 29, 2012 21:28 UTC (Sat) by geofft (subscriber, #59789) [Link]

There are two ways to use Persona:

1) If you have the appropriate setup in /.well-known/ via HTTPS, then authentication is through that key (specifically it accepts assertions signed by that public key).

2) If you don't, it falls back to a publicly-trusted Persona server, which at the moment is Mozilla (in theory it could be anything else, but Mozilla works well enough for now).

You get more control/security and more convenience if you do option 1 -- in particular, the way Mozilla implements option 2 is by doing the email-verification dance -- but both options work well enough.

Mozilla "Persona" beta release

Posted Sep 30, 2012 2:50 UTC (Sun) by geofft (subscriber, #59789) [Link]

It's a bootstrapping mechanism. Mozilla is not going to get instant buy-in from every single domain owner, so one way to use Persona is for the website that wants to do Persona logins to rely on Mozilla's central trusted Persona server, which in turn relies on actual e-mail verification. The other way is to bypass Mozilla's trusted server and rely on the domain implementing Persona natively.

If you as a domain owner don't want mail to be involved / want to make life easier for your users, implement Persona. If you as a domain owner don't care about Persona but run an email server, then anyone with an email address at your domain can still use Persona.

Mozilla "Persona" beta release

Posted Sep 28, 2012 15:18 UTC (Fri) by geisler (guest, #44380) [Link]

I think you're looking for this:

https://developer.mozilla.org/en-US/docs/Persona

Mozilla "Persona" beta release

Posted Sep 28, 2012 22:55 UTC (Fri) by alankila (guest, #47141) [Link]

Indeed. I now saw the protocol overview on that page.

I think this looks a whole lot like OpenID, in the end. In both cases you're supposed to run some web server software to handle the login process for relying parties. The only major difference is that instead of your identity being an URL, it's an email, but that email is converted to an URL by a convention, and that URL is then used to look up the API's relevant details.

Mozilla's additional trick here is that if your email-like identity's provider doesn't support this protocol (the derived URL doesn't contain a valid document), they offer some kind of implementation which can do the authentication nevertheless. I presume *that* does send emails to the address, and you have to read them and maybe follow a link or copypaste some token from that email to prove that you can read messages sent to that email address.

Mozilla "Persona" beta release

Posted Sep 29, 2012 21:30 UTC (Sat) by geofft (subscriber, #59789) [Link]

Yeah, that's exactly correct. I'd prefer to introduce myself as geofft@example.com than http://example.com/user/geofft. And in particular, you can contact me in some well-known way (email) and possibly other ways (Jabber?) through that first address, whereas that second address is _only_ an OpenID identity.

The WebFinger home page makes this point in more detail, and Persona is heavily inspired by WebFinger.

Mozilla "Persona" beta release

Posted Oct 1, 2012 1:48 UTC (Mon) by roc (subscriber, #30627) [Link]

BrowserID has other advantages over OpenID. It has a big privacy advantage: with OpenID, your OpenID provider is informed of every site you log into, every time you log into it. It's like the government being informed every time you present your driver's license as ID. (Actually worse, since the ID provider can selectively deny authentication on a site by site basis.)

With BrowserID an ID provider can at most deduce (via its key being fetched) that *some* unspecified user is logging into a particular site, and because the key is cached this notification only happens once in a while (e.g. every 12 hours).

Mozilla "Persona" beta release

Posted Oct 4, 2012 9:39 UTC (Thu) by alankila (guest, #47141) [Link]

This is an excellent point. I agree that this change turns me far more enthusiastic about Persona, because there is no real reason for openid provider to know about the sites I visit.

Mozilla "Persona" beta release

Posted Oct 8, 2012 3:43 UTC (Mon) by ras (subscriber, #33059) [Link]

> It has a big privacy advantage: with OpenID, your OpenID provider is informed of every site you log into, every time you log into it.

Yes, this is true. But OpenID implemented well reveals nothing about you to the site you are logging into. They just get a nonce. And while it is true your OpenID provider does get to see your login, you can choose your OpenID provider and chain them.

Persona also has a big disadvantage: it uses the same unique user name for every site. So if sites cooperate they can track your movements without your knowledge.

So they both have bad sides. I think Persona's is worse. While is is true my OpenID provider does get to see all my logins, I get to choose my OpenID provider. I could even set up my own provider, if I so choose. But say if I want to use say Twitter with Persona, then I don't have the choice of choosing some other "Twitter provider" because I trust them more with my email address.

This was a really odd design choice by the Persona developers. I can't understand why they designed an auth protocol they forces you to or remember any identifier (or "principle" in the parlance used by the Persona spec) - be it an email address or anything else. The association should be between one meaningless nonce and another, nothing more. If the use case then warrants tying other data to that association, like an email address, name, phone number or whatever than that's fine, but the protocol shouldn't force that onto you.

Mozilla "Persona" beta release

Posted Oct 8, 2012 4:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, since OpenID uses a URL as an identifier, then it can be used to track you just as easily.

And Persona doesn't preclude the use of ephemeral names like N123123@nopersona.org (which I've just registered) to make tracking more complex.

I mostly see the unified name as a feature, not a bug.

Mozilla "Persona" beta release

Posted Oct 8, 2012 4:18 UTC (Mon) by ras (subscriber, #33059) [Link]

> since OpenID uses a URL as an identifier, then it can be used to track you just as easily.

No so.

Yes, it uses a URL. But as of version 2 a provider can provide the same login URL for all users. Google's implementation does this. I would not use any OpenID provider that didn't do it, which among other things means I wouldn't use any provider who only implements version 1.

Mozilla "Persona" beta release

Posted Sep 28, 2012 22:33 UTC (Fri) by elanthis (guest, #6227) [Link]

Dude. The thing is fully documented, quite well. It does not require any Mozilla services, but Mozilla is hosting the initial fallback service until more providers come about and browsers start building Persona in to the UI. The JS restriction is because this is an early alpha, so no business should be relying on this yet, because that would be stupid, hosted on mozilla.org or not.

Mozilla "Persona" beta release

Posted Sep 29, 2012 21:44 UTC (Sat) by geofft (subscriber, #59789) [Link]

Re point 1, the email is sent by Mozilla's servers, not by the browser or the JS running in the (untrusted) browser.

Namely, Persona requires relying on some party for verification. As described elsewhere in the thread, this could be the party owning the website, but defaults to Mozilla's own servers. For that to work, Mozilla needs to send the email themselves -- they can't trust the user's browser to send the email.

How the identity verifier actually goes about verifying identities is beyond the abstraction barrier that the browser cares about. Either the JS implementation or the built-in server will generate a request to the appropriate verifier, saying, "Please give me a signed message I can pass back to this website." If the verifier is Mozilla, this results in Mozilla sending an email, but the browser doesn't need to know that. If the verifier is some ISP or corporate site or something, maybe they can do out-of-band verification.

(And, in any case, JS in the browser has no ability to send emails.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds