6 ms·

I am still waiting for digital identity. Not sure why I can’t authenticate myself with these companies based on a private key and any details they want be disc

by Affric 3y ago

I am still waiting for digital identity. Not sure why I can’t authenticate myself with these companies based on a private key and any details they want be disclosed to them for whatever reason don’t just come ephemerally from my server. Obviously, you could also have a third party acting in this space for the non-tech savvy. Right now all my data is held by corporate types who don’t give a shit.

mooreds 3y ago
Passkeys are a start. They have their issues (I wrote about some here: https://ciamweekly.substack.com/p/on-webauthn-and-passkeys https://ciamweekly.substack.com/p/on-webauthn-and-passkeys ) but at least it is widespread, well supported, standardized, (possibly) anonymous public private key cryptography.
- __MatrixMan__ 3y ago
  It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server side component. It's not just a key in your device, it's a key in your device that's blessed by someone who maintains a server. My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other. They can say: > sorry passkeys.jimbobsmomsbasement.com, you're not on the list of servers that I trust, so I'm not going to accept this key Quoting GP here: > Right now all my data is held by corporate types who don’t give a shit. Is it true that passkey providers will be able to use this feature band together and prevent passkey providers that they don't like from being useful? It was something about attestations--I didn't fully get it the first time it was explained to me. If so, doesn't that make the "corporate types who don't give a shit" problem worse? At least with a password the corporate types couldn't deny you the right to authenticate because in their estimation your password provider isn't corporate enough.
  - hirsin 3y ago
    It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employees Yubikey 3s", they can instruct their idp to only accept passkeys for Yubikey 3s. This is a tradeoff - their employees can't register legitimate, useful personal passkeys like their phone, but an arbitrary (not dedicated nationstate) attacker is a bit less likely to somehow takeover the account and add a Feitian key. That mismatch is a nice signal to block the user. But in general, outside of corporate identities, no one has any interest in caring what kind of passkey you use. GitHub doesn't, certainly, outside of resident key requirements, a different bundle of fish. (and yes, Dan is definitely great at this stuff, read his blog on this stuff).
    - __MatrixMan__ 3y ago
      I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure. The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only collects a retinal scan, not also DNA, or somesuch, and now we're in a race to the bottom re: just how authenticated one can be.
      - juped 3y ago
        It's hardly tinfoil hattery. If it isn't that (and I'm still not convinced by all the above that it isn't) then it needs to explain exactly how it isn't loudly, repeatedly, clearly, and very prominently.
        __MatrixMan__ 3y ago
        The messaging around it sure has been heavy on the "you should do this it's better" and light on the "and here are the implications".
- yau8edq12i 3y ago
  Passkeys simply authenticate a device + maybe a PIN. Not a person.
shicholas 3y ago
The Schluss project out of the Netherlands is trying to do just that, really cool stuff! (Schluss.org)
canadiantim 3y ago
For a third party acting in this space who could provide a server for the non-tech savvy, what do you think the ideal setup is, infrastructure and architecture wise?
ahaseeb 3y ago
some of it has to be with regulations where data retention is required by the law ( Fintech/Telco). Other than that it's to learn more about client and use the data to reach more clients. In a perfect world, we should have the right to revoke our data access anytime we want, specially when there is a material change in management ( Exit/Acquired/CoFounder left) etc.

by Affric 3y ago

mooreds 3y ago

Passkeys are a start. They have their issues (I wrote about some here: https://ciamweekly.substack.com/p/on-webauthn-and-passkeys https://ciamweekly.substack.com/p/on-webauthn-and-passkeys ) but at least it is widespread, well supported, standardized, (possibly) anonymous public private key cryptography.

__MatrixMan__ 3y ago
It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server side component. It's not just a key in your device, it's a key in your device that's blessed by someone who maintains a server. My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other. They can say: > sorry passkeys.jimbobsmomsbasement.com, you're not on the list of servers that I trust, so I'm not going to accept this key Quoting GP here: > Right now all my data is held by corporate types who don’t give a shit. Is it true that passkey providers will be able to use this feature band together and prevent passkey providers that they don't like from being useful? It was something about attestations--I didn't fully get it the first time it was explained to me. If so, doesn't that make the "corporate types who don't give a shit" problem worse? At least with a password the corporate types couldn't deny you the right to authenticate because in their estimation your password provider isn't corporate enough.
- hirsin 3y ago
  It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employees Yubikey 3s", they can instruct their idp to only accept passkeys for Yubikey 3s. This is a tradeoff - their employees can't register legitimate, useful personal passkeys like their phone, but an arbitrary (not dedicated nationstate) attacker is a bit less likely to somehow takeover the account and add a Feitian key. That mismatch is a nice signal to block the user. But in general, outside of corporate identities, no one has any interest in caring what kind of passkey you use. GitHub doesn't, certainly, outside of resident key requirements, a different bundle of fish. (and yes, Dan is definitely great at this stuff, read his blog on this stuff).
  - __MatrixMan__ 3y ago
    I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure. The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only collects a retinal scan, not also DNA, or somesuch, and now we're in a race to the bottom re: just how authenticated one can be.
    - juped 3y ago
      It's hardly tinfoil hattery. If it isn't that (and I'm still not convinced by all the above that it isn't) then it needs to explain exactly how it isn't loudly, repeatedly, clearly, and very prominently.
      - __MatrixMan__ 3y ago
        The messaging around it sure has been heavy on the "you should do this it's better" and light on the "and here are the implications".
yau8edq12i 3y ago
Passkeys simply authenticate a device + maybe a PIN. Not a person.

shicholas 3y ago

The Schluss project out of the Netherlands is trying to do just that, really cool stuff! (Schluss.org)

canadiantim 3y ago

For a third party acting in this space who could provide a server for the non-tech savvy, what do you think the ideal setup is, infrastructure and architecture wise?

ahaseeb 3y ago

some of it has to be with regulations where data retention is required by the law ( Fintech/Telco). Other than that it's to learn more about client and use the data to reach more clients. In a perfect world, we should have the right to revoke our data access anytime we want, specially when there is a material change in management ( Exit/Acquired/CoFounder left) etc.