OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.

▲

lapcat 5 days ago | parent [-]

Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.

▲

jmsgwd 5 days ago | parent [-]

Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?

▲

pseudalopex 5 days ago | parent [-]

Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.

[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

▲

jmsgwd 4 days ago | parent | next [-]

OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.

Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.

Or are you saying the credential exchange process itself could block providers?

	▲	pseudalopex 4 days ago \| parent [-]
		You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate.

▲

timmyc123 5 days ago | parent | prev [-]

Hi, Tim Cappalli here.

Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".

If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.

Always happy to chat directly if you have concerns!

▲

pseudalopex 5 days ago | parent [-]

The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment.

The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now?

The concerns were clear I thought. I would be happy to discuss this publicly.

▲

timmyc123 5 days ago | parent [-]

Attestation is not used in the consumer passkey ecosystem.

▲

pseudalopex 5 days ago | parent [-]

But it could be. Yes?

▲

timmyc123 5 days ago | parent [-]

Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.

▲

pseudalopex 4 days ago | parent [-]

> doesn't really work in practice

Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose?

▲

jesseendahl 4 days ago | parent [-]

In theory any code could be written at any time that does something good or bad. Sure.

But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.

	▲	deltoidmaximus 4 days ago \| parent [-]
		Will be a nightmare. If they really didn't want this they wouldn't have put the tool to do it right in the spec.