Using CryptoKey for public keys - what are the restrictions?

[marcoscaceres]

Right now, we had proposed passing around DOM strings for public keys... However, CryptoKey serves as a nice primitive we already have in the platform from Web Crypto.

I think we can reuse the crypto.subtle.subtle.importKey() method to get the CryptoKey, which we can then pass into requestIdentity() as part of the IdentityRequestOptions.

[OR13]

Does this issue imply mandatory support for jwk, pkcs8, and raw ?

Does this forbid certificates?

JOSE support for HPKE is just getting started, so it might be a while before you can easily use things like:

{
   kid: 'urn:ietf:params:oauth:jwk-thumbprint:sha-256:zLL3uvca9qDXqK1UysySHW720kcKVcEqOf7KBIVZg6Q',
   alg: 'HPKE-Base-P256-SHA256-AES128GCM',
   kty: 'EC',
   crv: 'P-256',
   x: 'W-70J8fA-XcYE3PiSIy_wNz-TQ_-j_QrOGLAo30YuN0',
   y: 'v6DySTYHurdTKwNa-AN7LwHSh-jN9x4a3uO1r38b1EI'
 }

[marcoscaceres]

I guess it would be whatever Web Crypto mandates for formats, as it's the one providing the API to create CryptoKey. We can further restrict that in our spec.

However, new format support would need to get added to Web Crypto so we could use them (if needed).

[jogu]

Can someone confirm if using Cryptokey allows us to preserve potentially important information like the 'kid' from a JWK please? From a brief read of the API it looks like that information would be lost.

[marcoscaceres]

Note that nothing need be "lost"... we can just amend Web Crypto if we need to and something is important to us.

What uses kid and why does it matter? (I know very little about JWK, so all 👂)

Also, please note that Cryptokey is just the exposed JS implementation... there may be some other way for the user agent to access the details of the key that are not necessarily exposed to JS.

[jogu]

Note that nothing need be "lost"... we can just amend Web Crypto if we need to and something is important to us.

Fair enough, but as per my comment on #49 I'm unclear why we even want to go in this direction.

What uses kid and why does it matter? (I know very little about JWK, so all 👂)

It's a key identifier. The header of an encrypted JWT usually includes the keyid of the key that was used to perform the encryption, so that when the encrypted JWT arrives at the verifier's backend it knows which key to try decrypting it with. (There are other ways to achieve the same result of course, but this is an existing commonly used mechanism.)

[marcoscaceres]

Answered #49 here: https://github.com/WICG/digital-credentials/issues/49#issuecomment-1909302430

It's a key identifier...

Ah right, ok... yeah, when the key eventually gets to the wallet, it will be in a format/structure that the wallet understands (it won't be a CryptoKey... that's just for browsers in JS land, but will be transformed into completely native on either iOS, Android, or Windows once it goes over IPC and hits the wallet or OS).