3 ms·

It seems all required is publishing a `/.well-known` URL that delegates to another provider, although it's not obvious if such a provider exists yet. Pretty co

It seems all required is publishing a `/.well-known` URL that delegates to another provider, although it's not obvious if such a provider exists yet. Pretty cool it's this straightforward, though.

JoshTriplett 14y ago
I don't want to delegate to another provider, though; I'd like to take advantage of the decentralized approach, and authenticate my own email address.
- tadfisher 14y ago
  What is your preferred server environment? This would be a fun project to whip up quickly.
  - JoshTriplett 14y ago
    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."
    - tadfisher 14y ago
      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.
      - JoshTriplett 14y ago
        > Throw a pregenerated cert into localStorage and sync across browsers. 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.
    - graue 14y ago
      This sounds awesome. I hope you do it and write a blog post about it!

It seems all required is publishing a `/.well-known` URL that delegates to another provider, although it's not obvious if such a provider exists yet. Pretty cool it's this straightforward, though.

JoshTriplett 14y ago

I don't want to delegate to another provider, though; I'd like to take advantage of the decentralized approach, and authenticate my own email address.

tadfisher 14y ago
What is your preferred server environment? This would be a fun project to whip up quickly.
- JoshTriplett 14y ago
  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."
  - tadfisher 14y ago
    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.
    - JoshTriplett 14y ago
      > Throw a pregenerated cert into localStorage and sync across browsers. 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.
  - graue 14y ago
    This sounds awesome. I hope you do it and write a blog post about it!