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

I've been reviewing a number of threads to find a way to store private keys with; or derive private keys from authenticator credentials in webapps. It looks like this use case has been considered a number of times (credBlob extension, this PRF extension, hmac-secret which is sooo close but not exposed to webapps). My search has led me here, and it seems that many of the experts are on this thread (though probably not paying attention given the time that has lapsed).

Before I get to my main points, I first want to emphasize: I really appreciate all the work and thought that has gone into this; and _I'm grateful to have smart and diligent people like you all on standards bodies_, constructively disagreeing and figuring out the best designs for new browser standards. Personally I'm frustrated to see the PRF extension removed (and therefore this functionality delayed), but I do appreciate the difficulty in creating a design that is cohesive in a complex and consequential domain.

1. It's possible this use-case is under-prioritized because of how the user scenario is summarized. I've seen in a number of threads that this use-case is summarized as "for example, password managers". It's true that password managers both need to authenticate the user, and prefer or need hardware-protected storage for private keys that can only be accessed by the verified user. But more broadly, this can be any app that wants a strong guarantee of data privacy (sensitive documents, financial info). My startup would like to be able to offer the guarantee: "no one else, including company employees, can access your data, because it is encrypted with keys that are only stored on your devices" (marketing version). Today this requires native apps to achieve, but I think it's important for the web platform that this be possible in web apps. In fact if a prescribed flow is provided for this use-case, I'm confident it will dramatically improve user data privacy on the web.

2. Given the predefined scope of WebAuthn (Authentication is in the name!) and WebCrypto (cryptographic operations, though nothing about storage), and given the many layers of WebAuthn (eg browser APIs, alignment with CTAP, alignment with the server verification for FIDO2), I understand the need to draw a hard line on anything that is not authentication. But conceptual scope and architectural scope are not always the same - sometimes we draw architectural lines for practical reasons.

I'm confident I'm missing a number of details, but it seems to me that if the PRF extension capability is moved to WebCrypto (which obviously hasn't happened in the past year), the following things will need to happen:

a. A new browser API set (working name: WebBiometricsCryptoStorage) is created to wrap interactions with authenticators. Its domain is user verification, origin-scoped credential storage and cryptographic primitives that can be performed on the hardware using hardware-resident keys, so it encompasses CTAP. It is broader than "just authentication". Its output can be used with WebCrypto, and it can be used to store keys generated by WebCrypto, but it's conceptually distinct.

b. WebAuthn is re-architected to call this new browser API, and updates to WebAuthn <-> authenticator capabilities also have to be negotiated through the standards body for WebBiometricsCryptoStorage. The use case for a user interacting with the authenticator once, while providing an authentication response for WebAuthn, and access to stored keys associated with the origin and user credential, would still need to be supported in WebAuthn.

While this approach seems conceptually purer, it seems impractical given where we are.



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


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

Received on Tuesday, 29 March 2022 05:57:26 UTC