3 ms·

By the way, neither identity protection nor reuse across browsers does not strictly require IdP. In a strict sense, you don't need a trusted third party to tran

By the way, neither identity protection nor reuse across browsers does not strictly require IdP. In a strict sense, you don't need a trusted third party to transfer data between your devices or have a means to recover a lost key. If you have everything you need to prove your identity claims, you can decide how you handle those on your own, and whenever you want some TTP assistance or not. And if you decide you do, the requirements are a lot more relaxed. With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity. However, if - for example - you have an identity asserted by a keypair - you have way more possibilities, ranging from a key backup in a tamper-resistant HSM in a safe vault behind a blast-resistant doors in your basement, or setting up a secret sharing scheme where 3 out of 6 your close friends must get together to help you recover a lost key, to just uploading your key to Dropbox and not giving a damn. Isn't that a good thing? And if the key's completely lost - it's the same as if the email provider's gone - you'll have to either give up or recover your accounts using some other ways (talking to a support and figuring out what would be a good replacement proof).

WorldMaker 11y ago
«By the way, neither identity protection nor reuse across browsers does not strictly require IdP.» Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. Users have trouble remembering passwords, key management is seemingly beyond most users. So too are systems like the "web of trust" model of key identification much to complicated (and onerous and time consuming) for the average user. IdP is the best bet we have of at least somewhat decentralizing trust decisions in a way that is user friendly. «With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.» This is not a requirement of Persona. You can use any email you like with Persona and it's not a platform requirement that user accounts in a system be one-to-one with email addresses. It's certainly possible a site using Persona can very easily tie multiple identifying emails to your account. It may not be likely that a lot of sites would do it, as one email, one person is a rather generally accepted identity world at the moment, but it's also not far fetched that the replacement for the "Forgot Password" button in a hypothetical universe where Persona is the only option is a "Associate another email address to your account" button. «However, if - for example - you have an identity asserted by a keypair» But what good is this assertion? How do I as an application provider trust your assertion? At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". You could self-assert an email address or a name/pseudonym, fine, but as an application provider I can't make any assumptions about the contents of that email address or name/pseudonym and the only trust I have in it is "your word". You could use web of trust assertions, but again we get into the bootstrapping issue of "web of trust is hard" and "users don't want to have to do it". The same goes for all of your hypothetical key management: yes, you can manage a key on your own cognizance in any number of ways. Ultimately, most people just don't want to. On the flipside, Persona too has more options in this space for IdP management and key management than maybe you've given it thought: There's a Mailinator-based IdP that will sign any key request from Persona for pseudonymous identities (while even maintaining the application provider assertion that the email is valid and accessible to that user). There's the ability to do IdP delegation from a domain, using a file on my website to choose which IdP I trust right now, which can easily change over time. (Static HTTP sites on custom domains are cheap as free, including Github Pages as one option.) There are more ideas out there and you can reasonably approximate whatever half-finished idea you have for your own key management system with Persona given a little bit of time and elbow grease.
- drdaeman 11y ago
  > Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. So, let them put their unencrypted keys on, err, Firefox Sync or Dropbox or whatever, and not give a damn. It would be almost exactly the same security level - identity conveniently secured by an external service. I just don't see a downside. Yes, the keypairs don't have a human-readable name - but they don't have to, they're just like passwords, except for they can be globally recognized (if user wants to). Yes, for non-paranoid users' convenience we need some sort of key escrow system with some trusted party that can take hold of a file - but that's well possible and I think every other user has some "cloud storage" those days. > This is not a requirement of Persona. Yes, you're right. I simplified it a bit. A requirement of Persona is that IdP is a very specific service identified by a domain name, not an email. But the rest of logic should still hold. > How do I as an application provider trust your assertion? Generally, you don't need to check assertions, unless you want to confirm that this specific user has some affiliation with this specific third party. Then you check a signature from that party. If you don't need an information that your user is also a specific person on, say, Facebook, or, say, a representative of some company (verified by a notary) - you don't need to care about any assertions. You just take a key and that's it. Seriously, an average service does not need any identity assertions. Do you need a passport to enter a restaurant or a store? It's the same thing here. (Ok, maybe you do if that's a gun or liquor store, or some private lounge that needs a membership.) Oh, and, sure thing, almost every store out there would just love to ask for a passport and have a very detailed and extensive tracking of their visitors. > At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". Neither do I, but I don't see why you thought about using fingerprints as identifiers for humans. Those are credentials, not identities, although they're tied because it's hard to separate the concepts. Users already have a lot of weird stuff but and don't care that they're username/pbkdf2_sha256$12000$6Q0D5rq4nz1m$xsAqY1hlIuFqY4sD+9Ia0dxNLooy+jmHFJCrBgByhHw=. Let us leave those details to computers. Hope you see the idea.

WorldMaker 11y ago

«By the way, neither identity protection nor reuse across browsers does not strictly require IdP.» Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. Users have trouble remembering passwords, key management is seemingly beyond most users. So too are systems like the "web of trust" model of key identification much to complicated (and onerous and time consuming) for the average user. IdP is the best bet we have of at least somewhat decentralizing trust decisions in a way that is user friendly. «With Persona you trust a very specific third party - some email provider. You trust it to behave and you trust it to serve and stay so for as long as you need your identity.» This is not a requirement of Persona. You can use any email you like with Persona and it's not a platform requirement that user accounts in a system be one-to-one with email addresses. It's certainly possible a site using Persona can very easily tie multiple identifying emails to your account. It may not be likely that a lot of sites would do it, as one email, one person is a rather generally accepted identity world at the moment, but it's also not far fetched that the replacement for the "Forgot Password" button in a hypothetical universe where Persona is the only option is a "Associate another email address to your account" button. «However, if - for example - you have an identity asserted by a keypair» But what good is this assertion? How do I as an application provider trust your assertion? At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". You could self-assert an email address or a name/pseudonym, fine, but as an application provider I can't make any assumptions about the contents of that email address or name/pseudonym and the only trust I have in it is "your word". You could use web of trust assertions, but again we get into the bootstrapping issue of "web of trust is hard" and "users don't want to have to do it". The same goes for all of your hypothetical key management: yes, you can manage a key on your own cognizance in any number of ways. Ultimately, most people just don't want to. On the flipside, Persona too has more options in this space for IdP management and key management than maybe you've given it thought: There's a Mailinator-based IdP that will sign any key request from Persona for pseudonymous identities (while even maintaining the application provider assertion that the email is valid and accessible to that user). There's the ability to do IdP delegation from a domain, using a file on my website to choose which IdP I trust right now, which can easily change over time. (Static HTTP sites on custom domains are cheap as free, including Github Pages as one option.) There are more ideas out there and you can reasonably approximate whatever half-finished idea you have for your own key management system with Persona given a little bit of time and elbow grease.

drdaeman 11y ago
> Technically correct, but it makes it a lot easier at a practical level, especially for non-technical users. So, let them put their unencrypted keys on, err, Firefox Sync or Dropbox or whatever, and not give a damn. It would be almost exactly the same security level - identity conveniently secured by an external service. I just don't see a downside. Yes, the keypairs don't have a human-readable name - but they don't have to, they're just like passwords, except for they can be globally recognized (if user wants to). Yes, for non-paranoid users' convenience we need some sort of key escrow system with some trusted party that can take hold of a file - but that's well possible and I think every other user has some "cloud storage" those days. > This is not a requirement of Persona. Yes, you're right. I simplified it a bit. A requirement of Persona is that IdP is a very specific service identified by a domain name, not an email. But the rest of logic should still hold. > How do I as an application provider trust your assertion? Generally, you don't need to check assertions, unless you want to confirm that this specific user has some affiliation with this specific third party. Then you check a signature from that party. If you don't need an information that your user is also a specific person on, say, Facebook, or, say, a representative of some company (verified by a notary) - you don't need to care about any assertions. You just take a key and that's it. Seriously, an average service does not need any identity assertions. Do you need a passport to enter a restaurant or a store? It's the same thing here. (Ok, maybe you do if that's a gun or liquor store, or some private lounge that needs a membership.) Oh, and, sure thing, almost every store out there would just love to ask for a passport and have a very detailed and extensive tracking of their visitors. > At bare face value an "identity asserted by a keypair" is a fingerprint, a boring hexadecimal hash. I don't know very many people that associate themselves as "fe:02:aa:45:c3:d0". Neither do I, but I don't see why you thought about using fingerprints as identifiers for humans. Those are credentials, not identities, although they're tied because it's hard to separate the concepts. Users already have a lot of weird stuff but and don't care that they're username/pbkdf2_sha256$12000$6Q0D5rq4nz1m$xsAqY1hlIuFqY4sD+9Ia0dxNLooy+jmHFJCrBgByhHw=. Let us leave those details to computers. Hope you see the idea.