[Remote CryptoKeys] Option for key access to be tied to browser storage policy?

[RByers]

Since the keys here are remote, we'd obviously need to get user permission to use them, but it's unclear to me how such permission would be framed. Is this just another form of storage access API with a generic message that boils down to "do you trust this site to track you"?

We (Chrome) have anti-fraud use cases where we want keys that are tied to browser storage policy (origin-bound and partitioned). We're building DBSC with such a key storage model, and I think it might be interesting if we could architecturally think of it and Remote CryptoKeys as being built on top of the same underlying key access primitives (possibly with different options). @kmonsen @arnar WDYT?

Could you imagine offering an option in the API to generate and access keys in an origin-bound way? Obviously the physical keys would still be stored outside the browser, but they could be paired with a bit of browser storage which makes those keys useless and unavailable without it.

[estark37]

(Warning: this comment is possibly tangential to this issue, and also I might be confused!)
ISTM that even if the keys were tied to the browser storage policy, user consent would be necessary -- unless the origin-bound/partitioned keys were wiped when the user clears site data. And my understanding is that deleting the keys when the user clears site data wouldn't be plausible for some of the use cases, and might even be technically impossible in some cases (e.g., for keys stored on detachable hardware devices that aren't plugged in when the user clears site data). Seems like consent would be necessary to create a persistent identifier, even if tied to a single site.

[arnar]

I think @estark37 is right in that it might be hard to get the property that "keys are deleted when site data is cleared" in a very general case. I guess the only options here are to have origin binding in the protocol similar to WebAuthn (meaning this isn't just a plain sign/encrypt-arbitrary-data kind of API anymore); or to be able to require that the key material itself is embedded entirely in the keyHandle.

WebAuthn/FIDO credentials do have a notion of being resident or not -- non-resident keys are not physically stored on SKs, but wrapped and stored in the keyHandle returned from create. If you throw away the keyhandle the key is effectively gone. But this also means you must sync the keyhandles to enable using them on multiple clients.

WebAuthn in its authenticator model also has no way of requiring that keys are non-resident. All it cares is if credentials are "discoverable", meaning that e.g. an SK can enumerate the keys+keyHandles that it has. The API there only allows a website to require that a key is discoverable, which in turn requires it is resident. But. there's no way to require that it is non-resident.

As for the original question: DBSC makes a lot of assumptions, e.g. that the key storage facility it uses is strictly tied to the client device (e.g. computer) that the browser is running on. Keys have a similar scope to cookies, and cookies are not expected to be synced between multiple clients simultaneously. But istm this API specifically wants to enable such use cases - i.e. the user controls their private key and can even take it with them between different client devices. So I'm not sure the same primitives fit.

[dadrian]

origin binding in the protocol similar WebAuthn (meaning this isn't just a plain sign/encrypt-arbitrary-data kind of API anymore)

I don't see why origin binding would affect the functionality of the API, it only affects the visibility of a key to a website.

[jonchoukroun]

To clarify, the intent of this proposal is to support long-lived key use, across multiple browsers and user devices. For example, I can create an encryption key pair on my phone, which I use with a native app. But I also sync those keys to my laptop, where I use them in the browser. User consent will definitely be necessary, but probably cannot be enforceable in the spec. Most likely, implementers will handle user consent checks when the getRemoteKey call tries to bind a CryptoKey to some key material that exists in memory (or hardware) that’s inaccessible to the browser. How that consent is obtained and managed is out of scope for the proposal, we believe.

Could you imagine offering an option in the API to generate and access keys in an origin-bound way?

This is one of the open questions that we believe needs further discussion. Our use case would be served by an API that supports certificate/key generation, along with other PKI functionality. But that raises a number of issues, including the ability create a cross-browser, persistent user tracker. This proposal does intend for the keys to be origin-bound, as well.

[estark37]

This proposal does intend for the keys to be origin-bound, as well.

ISTM that this would have to be a different type of key -- one created and managed by the browser -- than one which is backed by e.g. a hardware device or exportable/importable across apps and devices. Otherwise it's not clear to me what it would even mean for a key to be origin-bound; presumably, whatever process the user goes through to import a key into the browser for use with Origin A, they could also follow the same process to use the key with Origin B.

[jonchoukroun]

@estark37 I think you're right. We've been thinking of these keys as origin-bound, in the sense that when a web app calls getRemoteKey() the browser would pass along the web app's origin, to be used in access control. But the spec won't be able to enforce that the keys themselves have metadata associating them with an origin.
For the purposes of this explainer, the properties we're aiming to achieve are:

• they key material is never exposed to webpage code, so we can't embed the key material in the keyHandle
• the key is long-lived; it's lifetime isn't bound to browser memory.