61–70 of 154 posts
I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit? [Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]
Earlier quoted context omitted.
Does this mean that your browser can cache the signed cert and log in to websites automatically without needing to even contact the provider again? I'm guessing there's some sort of timestamp there, to prevent someone from just stealing the cert and logging in to whatever they want as that user.
not different from someone stealing your cookies.
Earlier quoted context omitted.
Static files. :) Hence the idea of just pre-generating the key pair and sharing the key with my browsers via Firefox Sync. The provisioning and signin pages could point to static pages that just say "If you're seeing this, you're trying to authenticate as me and you aren't me; go away."
OK, so I can see this working with a browser extension. Throw a pregenerated cert into localStorage and sync across browsers. Where I'm still fuzzy is if the site performs local verification, or login.persona.org does it, it might contact your server to grab its pubkey over SSL, requiring you to host something on your email domain.
Browser extensions use their own secure storage mechanisms, not the localStorage used by sites, but yeah.
> Where I'm still fuzzy is if the site performs local verification, or login.persona.org does it, it might contact your server to grab its pubkey over SSL, requiring you to host something on your email domain.
Ignoring the workflow for domains without native identity providers (for which persona.org does its own mail-you-a-link validation), only one thing happens on the server accepting Persona: it requests the public key from the email domain. The site then expects to receive a message from the browser that chains back to that public key. So, you'd have to post some static files to /.well-known/ on your email domain, but the browser extension would construct the signed messages because it has the private key.
You could do this in two ways. For domains completely owned by the user, you could let the browsers hold the domain private key, and mint arbitrary identities on that domain on demand. For domains with multiple users but still wanting to statically manage identities, you could statically generate public/private keys for users and sign them with the domain key, then let the browsers hold onto the email keypairs only.
I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit? [Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]
If I knew your email, I could make an account on a website in your name without you knowing.
In that case is this not just functionally equivalent to sending a validation email upon account creation, as many sites do already?
I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit? [Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]
If I knew your email, I could make an account on a website in your name without you knowing.
If you know his email, then the website's confirmation link will still go to his inbox.
If you know his email and password, then Persona wouldn't help anyway.
I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overlo…
Earlier quoted context omitted.
I didn't downvote it but I think I know why: there's a huge wave of negativity on HN and your question sounds like criticism. There are ways to formulate the same question which would be much nicer and less negative, for example: "It's great to see other solutions providing things similar to OpenID. Can anyone explain what are the differences with OpenID?" Simply writing: "How is this different from XXX?" just sounds…
Understand where you are coming from but this is an overreaction. An HN where you have to wrap a plain, absolutely neutral question like this in a bunch of false praise or meaningless filler words is a much much worse place than the HN that might be overly critical/negative by default (and this perception is partly false, reinforced by the cultural belief that questions are attacks).
I don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit? [Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]
So the difference.
1 (Without Persona). You create an account on ABCforum.com with my-name@gmail.com as your username, and make up a random password. This is another account you always have to remember, and the password can be viewed by the developer behind ABCforum.com since it's stored in their database (which could also be hacked in the future). You get a verification e-mail sent to you, so ABCforum.com can confirm you own that e-mail.
2 (With Persona). You click login with Persona, and enter your gmail e-mail and password, which Google verifies belongs to you. There's no creating an account.
The provider (in this case Google Gmail) is confirming your e-mail and password, and not the site you're signing into (ABCforum.com).
I've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overlo…
Can JavaScript look up a SRV record?
> Of course, in the long term, Persona is meant to be distributed: alice@example.com should be verified and certified by the administrators of example.com. If example.com wants to use 2-digit passwords, they can. If they want to use retinal scans powered by your webcam, they can. It’s up to them. With each domain able to customize its authentication protocol with its users, the Web becomes more secure. How would a 2-…
He was just making a point that authentication protocol is a domain choice (from 2-digit passwords to retinal scan). It's up to the users to trust the domain he is going to use as identity. Just like many people trust Facebook Connect.
Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail?
Not in the sense of "these guys could compromise gmail" (which is a worry in certain elevated privileges contexts), but more in the sense that "people are still going to say 'my gmail got hacked'" if their gmail gets hacked because they made bad choices. They do now!
Google will still get blamed, and their only real option is to decide not to accept certain identity providers (IE blacklist or whitelist). Long term, how are we not going to end up with just a mishmash of who accepts what?
I've read a bunch of docs on persona, and it doesn't seem to address this past stating how wonderful user choice is, and how making this more distributed will make the web more secure (which seems, well, wrong)