Passkeys will be the way to go if we get them to remove the "attestation object" field from the protocol. Until then there's no way for Jimbob to tell the difference between:

> Website: is this Jimbob' phone

> Hardware: yes

And

> Website: I'll give you a dollar if you tell me something juicy about this user

> Hardware: Give this token to Microsoft and ask them

> Microsoft: Jimbob is most likely to click ads involving fancy cheeses, is sympathetic to LGBTQ causes, and attended a protest last week

With passwords and TOTP codes, I am in control of what information is exchanged. Passkeys create a channel that I can't control and which will be used against me.

(I chose Microsoft here because in a few months they're using the windows 10->11 transition to force people into hardware that locks the user out of this conversation, though surely others will also be using passkeys for similarly shady things).

▲

timmyc123 9 days ago | parent [-]

> Passkeys will be the way to go if we get them to remove the "attestation object" field from the protocol.

I don't think you understand the protocol. The attestation object does not mean there is an authenticator attestation.

There is no authenticator / credential manager attestation in the consumer synced passkey ecosystem. Period.

▲

__MatrixMan__ 8 days ago | parent [-]

Is this not the protocol we're talking about? https://w3c.github.io/webauthn/#sctn-attestation

It seems pretty clear that "where possible" parties besides the user are provided with information about the user (ostensibly about their device, but who knows what implementers will use this channel for)... so they can make a trust decision.

It's going to end up being a root-of-trust play, and those create high value targets which don't hold up against corruption, so you're going to end up with a cabal of auth-providers who use their privileged position to mistreat users (which they already do, but what'll be different is that this time around nobody will trust that you're a real human unless you belong at least one member of this cabal).

▲

timmyc123 8 days ago | parent [-]

Just because an API or protocol has a certain capability, does not mean it is implemented for all use cases.

Folks seem to be hung up on the term "attestation" being in the response of a create call. If you look inside that object, there is another carve out for optional authenticator attestation, which is not used for consumer use cases.

I will keep repeating what I've said in the other comments. There is no credential manager attestation in the consumer synced passkey ecosystem. Period.

▲

__MatrixMan__ 8 days ago | parent [-]

OK, so suppose you and I were bad guys. You work on the code that interfaces with the TPM on a windows device, and I work at an insurance provider and write code that authenticates users.

Suppose we hatch a conspiracy to take our users out of the "consumer synced passkey system". And into one where you can use the authentication ritual as a channel where you can pass me unique bits re: this user such that we can later compare notes about their behavior.

What about passkeys prevents us from doing this? How do we get caught, and by whom?

	▲	timmyc123 7 days ago \| parent [-]
		I'd say: 1) That would be a whole lot of work, collusion, etc for a very limited scope and outcome, which makes it incredibly unlikely to happen in practice. 2) If a credential manager decides to do shady things that you don't like, you can change your credential manager. That's the beauty of an open ecosystem. 3) There are much easier ways to track users online...(unfortunately)