Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
othermaciej opened this issue Mar 23, 2024 · 2 comments

Comments

@othermaciej
Copy link
Contributor

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
Copy link

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
Copy link

twiss commented May 22, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants