We have code scattered around to convert keys between different formats/representations:
DID Verification Method
JWK
Key bytes (sometimes in multiple different formats between uses) + kms.KeyType
standard library crypto keys (ecdsa.PrivateKey, etc)
Tink key handles & KMS Key IDs
I'm thinking we should make JWK the primary representation (outside of KMS/Crypto), since we already have support for converting to/from JWK for stdlib crypto keys, and bytes+kms.KeyType. For Tink key handles & KMS Key IDs, the KMS api supports converting to/from bytes+kms.KeyType - helper functions could consolidate to pass/receive JWK directly, and potentially update KMS API in future. DID Verification Methods either hold a JWK, or encoded key bytes with a type identifier (different from kms.KeyType), so VerificationMethod could get an API upgrade to support returning non-JWK keys as JWKs.
We have code scattered around to convert keys between different formats/representations:
I'm thinking we should make JWK the primary representation (outside of KMS/Crypto), since we already have support for converting to/from JWK for stdlib crypto keys, and bytes+kms.KeyType. For Tink key handles & KMS Key IDs, the KMS api supports converting to/from bytes+kms.KeyType - helper functions could consolidate to pass/receive JWK directly, and potentially update KMS API in future. DID Verification Methods either hold a JWK, or encoded key bytes with a type identifier (different from kms.KeyType), so VerificationMethod could get an API upgrade to support returning non-JWK keys as JWKs.