Open
Description
Hi! Here are some thoughts and suggestions on the “remote” CryptoKeys explainer.
First of all, as an aside, I wanted to mention that there is an old proposal for key discovery in Web Crypto. To my knowledge it was never implemented, and I assume it doesn't meet your needs, but it may serve as an inspiration for the spec, and I think there are some differences that would be good to copy here, more on which below.
First, some high-level questions:
- The high-level proposal seems to imply that the key is only queried when you actually try to use the
CryptoKey
object returned bygetRemoteKey
, but the description ofgetRemoteKey
does describe querying for a key and throwingNotFoundError
if none is found. Which is intended? (I think the latter seems more useful, so that the application knows as soon as possible whether it has a key it can use.) - Is there any intention to allow generating a key via this API? The proposal doesn't explicitly mention it, but the UI could offer to generate a key, if the user doesn't have one?
- Is there any intention to allow querying or generating two keys at once, for example both a signing and encryption key? It would seem onerous to make the user go through the UI flow twice. Or perhaps the access control and user consent parts could be cached, at least?
- Taking a step back to the use case of email, for example, is the browser expected to manage S/MIME and/or OpenPGP certificates that it returns a handle to the key material for here, or is the application expected to construct a certificate using the key returned here?
Then, some more low-level nitpicks:
- I think it would make the most sense to define a
interface RemoteKey : Key
, and put the remote-key-specific fields on the key directly, rather than on the algorithm, and leave the algorithm field intact, since the format of the key material differs per algorithm, so a given key can't be used with any algorithm. - Similarly, for requesting a remote key, I wouldn't let
RemoteKeyParams
extendAlgorithm
, and only include the params that can be used to query a key (i.e. removeexpiresAt
, presumably). Also,name: "remote"
seems redundant, and it would seem useful to me to also (separately) pass the algorithm that the application wants a key for? Otherwise, the browser doesn't know what kind of key to query (or generate).- Alternatively, if you want to be able to query any type of key, it becomes even more important to have the
remoteKey.algorithm.name
indicate the algorithm that the key is intended to be used with (since the parameters required to use the key differ per algorithm). But, doing it that way also seems risky because the application would need to have support for all algorithms that the key's intended algorithm could possibly be. So it would seem better to me to allow passing the (list of?) algorithm(s) that the application supports.
- Alternatively, if you want to be able to query any type of key, it becomes even more important to have the
- Finally, a naming nitpick: "remote keys" sounds a bit scary, as if they're stored on a server or so. Perhaps "user keys" would sound more friendly? That would also nicely align with
UserKey
having auserIdentifier
property, for example.
Metadata
Metadata
Assignees
Labels
No labels
Activity