[Remote CryptoKeys] “remote” CryptoKeys should be renamed, suggest “syncable”

[othermaciej]

There’s no spec-meaningful way here in which the keys specified are “remote”. Specs can’t define where the key material is at rest or in memory. The distinct property of these keys that is observable and not an implementation detail is that they can sync between the user’s devices. A potential secondary benefit is that they can be written or read by certain native apps, but we may need a registry specifying how this is done for each distinct platform.

[jonchoukroun]

We agree that ”remote“ may not be the correct term for these keys. However, it seems that it should be observable from the browser’s perspective that the key material exists in memory that is inaccessible to the browser. Another related property of these keys that should be observable is that they’re long lived. Clearing browser storage should not delete the actual key material (even if the CryptoKey handle itself is destroyed). How about a name like PlatformCryptoKey?

[twiss]

FWIW, in #110 I proposed UserKey, to reflect that this is a key that belongs to the user (which also sort of implies they should be synced between their devices). IMHO, PlatformCryptoKey sounds like it refers to a key that belongs to the platform somehow. But keeping Crypto in there might be good, so perhaps UserCryptoKey could work?

[jht5945]

Will ExternalKey make sense? External means this key is not in browser memory, the keys can stored in TPM/TEE/SE or other external devices(via PKCS#11).

P.S. Firefox allows me store certificates in Smart Card via PKCS#11, and I think it is a good idea.

[filip26]

Please let's consider another perspective: OS-native keyrings. These are already available on users' computers and support integrations with hardware wallets, etc., making them valuable to include.

Regarding terminology, I'm not sure "External" is the best choice. It implies something outside the browser, but that may not be clear to users and could instead evoke the idea of an external device.

Perhaps the core issue lies in distinguishing between browser-based and non-browser keyrings. However, since browsers don’t provide standardized embedded keyrings, this distinction might not be necessary or intuitive.

What about using [Crypto]KeysProvider as a more neutral abstraction, allowing users to choose their preferred keyring, or something like that? It would feel clearer and more flexible.