14 ms·

How does Persona avoid the identity provider seeing what services you log into? (Assuming the provider has implemented the distributed version of the protocol,

How does Persona avoid the identity provider seeing what services you log into? (Assuming the provider has implemented the distributed version of the protocol, not Mozilla's fallback IdP)

callahad 14y ago
Check out around the 16:00 mark in this video: https://www.youtube.com/watch?v=nJff23UdNAI https://www.youtube.com/watch?v=nJff23UdNAI Notice that provisioning (steps 1 and 2) and logging into a site (steps 3 and 4) are two completely independent processes, with the browser mediating any identifiable identity-provider-to-target-site communication.
subleq 14y ago
Persona stores a signed statement from the IdP in your browser (currently using localStorage). Once you get the statement from your IdP verifying your identity, you can log in using the same proof many times without contacting the IdP, until it expires.
csense 14y ago
The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider). The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the service as one of its users. Once the service has the provider's public key, it can be cached by the service until it expires, and while it's cached, the service can verify logins without contacting the server again by checking that the cert presented by the user to the service has a legitimate signature from the identity provider's public key. So if someone logs into HN using their Gmail ID (assuming both services grow support for the protocol), all Gmail knows is that at least one person attempted to log into HN using a gmail address. Who was trying to log in, whether that login was successful, and the number of other people who logged into HN with Gmail after that, are all facts that would be completely hidden from Google.
- StavrosK 14y ago
  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.
  - marcioaguiar 14y ago
    not different from someone stealing your cookies.
    - StavrosK 14y ago
      Cookies can be invalidated. Signatures, not so much.
      - sp332 14y ago
        It's possible to revoke a certificate. Not sure if that's what you're supposed to do in this case, but it's possible.
  - badida 14y ago
    Yes, that is exactly right, and it's also why certs are short-lived (hours). When certs are renewed, the site the user plans on logging into is not revealed to the Identity Provider.
  - brendn 14y ago
    By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.
- anologwintermut 14y ago
  This is an incomplete definition of privacy. If the service and server collude, you are hosed. There are cryptographic constructions(anonymous credentials) that have been around for over a decade that prevent this. IBM and Microsoft both have (unfortunately incompatible) libraries that do this. If we really are trying to build the id scheme of the future, why not use these?
sergiosgc 14y ago
https://developer.mozilla.org/en-US/docs/Persona/Protocol_Overview https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov... In short, your browser asks the identity provider to sign a certificate proving that you are someone@example.com. The browser will then use that certificate to authenticate you on the site. The site can check this certificate by getting the pubkey from the identity provider. You are never associated with the site you are authenticating against (except on very low traffic identity providers)

How does Persona avoid the identity provider seeing what services you log into? (Assuming the provider has implemented the distributed version of the protocol, not Mozilla's fallback IdP)

callahad 14y ago

Check out around the 16:00 mark in this video: https://www.youtube.com/watch?v=nJff23UdNAI https://www.youtube.com/watch?v=nJff23UdNAI Notice that provisioning (steps 1 and 2) and logging into a site (steps 3 and 4) are two completely independent processes, with the browser mediating any identifiable identity-provider-to-target-site communication.

subleq 14y ago

Persona stores a signed statement from the IdP in your browser (currently using localStorage). Once you get the statement from your IdP verifying your identity, you can log in using the same proof many times without contacting the IdP, until it expires.

csense 14y ago

The service you log into knows the identity provider's public key and a cert for the user (the user's public key signed by the identity provider). The service can verify the user's cert against the identity provider's public key with this information. The service initially contacts the identity provider to get the provider's public key, so the identity provider can infer that someone is attempting to log into the service as one of its users. Once the service has the provider's public key, it can be cached by the service until it expires, and while it's cached, the service can verify logins without contacting the server again by checking that the cert presented by the user to the service has a legitimate signature from the identity provider's public key. So if someone logs into HN using their Gmail ID (assuming both services grow support for the protocol), all Gmail knows is that at least one person attempted to log into HN using a gmail address. Who was trying to log in, whether that login was successful, and the number of other people who logged into HN with Gmail after that, are all facts that would be completely hidden from Google.

StavrosK 14y ago
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.
- marcioaguiar 14y ago
  not different from someone stealing your cookies.
  - StavrosK 14y ago
    Cookies can be invalidated. Signatures, not so much.
    - sp332 14y ago
      It's possible to revoke a certificate. Not sure if that's what you're supposed to do in this case, but it's possible.
- badida 14y ago
  Yes, that is exactly right, and it's also why certs are short-lived (hours). When certs are renewed, the site the user plans on logging into is not revealed to the Identity Provider.
- brendn 14y ago
  By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.
anologwintermut 14y ago
This is an incomplete definition of privacy. If the service and server collude, you are hosed. There are cryptographic constructions(anonymous credentials) that have been around for over a decade that prevent this. IBM and Microsoft both have (unfortunately incompatible) libraries that do this. If we really are trying to build the id scheme of the future, why not use these?

sergiosgc 14y ago

https://developer.mozilla.org/en-US/docs/Persona/Protocol_Overview https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov... In short, your browser asks the identity provider to sign a certificate proving that you are someone@example.com. The browser will then use that certificate to authenticate you on the site. The site can check this certificate by getting the pubkey from the identity provider. You are never associated with the site you are authenticating against (except on very low traffic identity providers)