Re: [webauthn] Move PRF Extension into its own specification (#1462)

I'm going to condense your points quite considerably here when referencing them but I'm not intending to strawman them, so if you believe that I've missed the mark please take that as an honest misunderstanding and let me know. (I'm also going to reorder them to put what I think are more minor points later.)

> This should be done in WebCrypto instead.

The user-presence and user-verification properties of the protection offered by the PRF extension are valuable, but they're also expensive because they require the human at the computer to touch, enter a PIN, or do a fingerprint read. If getting hardware-backed keys is a separate step then we force sites to choose between strong sign-in or strong key protection, because to get both you have the terrible experience of making people do all that twice in a row.

If a site is happy to do make people do an extra ceremony to get encryption keys then they can already get hardware-backed keys from WebAuthn, although I fear that you'll target that if I point out how. But the PRF extension is largely a convenience to merge two ceremonies into one.

Moving this to WebCrypto also means importing half of WebAuthn into WebCrypto. WebAuthn is problematically complicated already, forking half of it and putting it into WebCrypto would be very sad. It would also then diverge and I expect sites that wanted to use both would end up in situations where only WebAuthn worked for them because WebCrypto hadn't caught up in some respect.

> People will be confused that they need to use `publicKey` members and that they get signatures back when all they want is the symmetric key.

I see this is a _positive_. People should feel a little odd about all the extra machinery if they're ignoring it. What should they use the signature for? They should use it for _logging in_! I have no problem nudging people, who are using the backend machinery anyway for key protection, to also protect sign-ins. If there are people in the set of those who want hardware-backed key protection, but love phishing, then they're hardly over-burdened: they have to ignore some asymmetric cryptography terms and some extra struct members. Seems like a weak nudge, honestly.

> “It relies on the CTAP2 wire protocol”

Obviously it was designed to be able to work _with_ CTAP2, as a reflection of the amount of compatible hardware. But the PRF extension already includes provision for evaluation at credential-creation time that cannot be implemented on CTAP2, but which can be implemented over other transports, and which we hope(d) to do.

> It'll be easier to extend in WebCrypto

I think the PRF extension provides a flexible building block, and I'm not sure what such extensions could look like. M-of-N shares? Encrypt the shares as you would any other data, using PRF-supplied keys, and combine using Shamir's scheme.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1462#issuecomment-666543673 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 July 2020 17:25:38 UTC