Live data from Hacker News

Introducing Mozilla Persona, An Identity System for the Web

mozilla.org

41–50 of 131 posts

Re: Introducing Mozilla Persona, An Identity System for the Web

#42
post #6

Honest question: As an app builder, why would you use this instead of facebook? Many more users are going to have Facebook logins already, and it provides social information that may be useful to your app. (Hoping to hear answers other than the dev-centric 'I don't like facebook')

I have a facebook account, but I don't trust them enough to allow them to know anything about me except what I intentionally put on facebook. Thus, I don't use products that require me to authenticate with facebook. I will, however, authenticate with Google or a password. And, I would use Persona.

I'm simply not trusting facebook under any circumstances. I'm in the minority, I know. But, if you want my money, or my time, on your web app (and maybe you don't; maybe you want people who have low desire for privacy or security, since they're probably more likely to click on ads), you're gonna have to offer something other than facebook for logging in.

Re: Introducing Mozilla Persona, An Identity System for the Web

#45
post #2

Now if we can just get Chrome to agree on the same protocol.

Technically, this will work with chrome as-is, it just won't have a slick native interface. The basics are already implemented by Mozilla as a HTML/js library you can use on any browser.

Re: Introducing Mozilla Persona, An Identity System for the Web

#46

I really, really like Persona. It's federated and it gives the identity provider a vast amount of control over the security protecting accounts. Want to use SSH keys for auth? Okay. You can do that.

Do you have any links to specifications on it? I'm very interested on identity federation. But the post doesn't give away much info on persona's capabilities.

Re: Introducing Mozilla Persona, An Identity System for the Web

#47
I read a comment that the email provider can allow anyone to log into your accounts because they can sign any public key they want to say it's valid. This seems to be true from my 10 minutes reading the spec.

I know a password reset function that uses only email is basically the same level of trust in the email provider, and I'm no fan of email based password reset, but this feels even worse -- literally abdicating your security entirely into your email providers hands? Gmail is great because it's free, but I didn't join gmail with the idea of giving them the keys to my life.

Another thing I don't fully grok yet is the 'issued-by' concept. Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?

Finally, in a native implementation, how is the keyring persisted on disk kept safe from malware extracting your private keys? If the browser can decrypt the keyring, so can malware.

Ok I lied, one more thing... Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?! Then of course the next question is, how do you tell your browser you are walking away (akin to logout) and is it going to expire all sessions that were tied to your identity when that happens? So much to worry about...

Re: Introducing Mozilla Persona, An Identity System for the Web

#49

One of the reasons FB and Twitter OAuth became so popular is because they solved a problem for the user (remembering passwords) and also gave the site owner a big carrot (social growth mechanics, more user data). This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.

More power to the user is good. Current IdM solutions leak too much data to the service providers/relying parties. What really sucks about all solutions is that once the data has leaked, you gotta trust the service providers not to sell or give your data away.

I've wondered about "data-renting" setups before. For example, rather than giving a company my postal address, give them a token they can send to, and a post fulfilment company delivers to the actual address. If the address moves, the token follows. If I decided to revoke the token, they can't send me mail.

Can't do that with all digital data, but you could with e.g. email addresses, cc's, addresses, maybe phone numbers.

Re: Introducing Mozilla Persona, An Identity System for the Web

#50
post #2

Now if we can just get Chrome to agree on the same protocol.

Technically, this will work with chrome as-is, it just won't have a slick native interface. The basics are already implemented by Mozilla as a HTML/js library you can use on any browser.

It wouldn't even be that hard to have an extension scan the dom and offer the signed assertion automatically as Firefox would/could.
Post reply on HN