`CredentialRepositoryV2`: more ways to create COSE keys would be convenient

[iaik-jheher]

Picking this back up since our prototype from last year is finally being moved towards production :)

CredentialRecord (the interface type for CredentialRepositoryV2) requires implementers to provide a getter the COSE-encoded public key. Its javadoc refers to a convenience helper cosePublicKeyFromEs256Raw for converting from ES256 raw to COSE.

Would it be possible to add an additional helper for converting from java PublicKey to COSE? (This is adjacent to #288 from last year.)

---

Our business case: we need to submit the credential public key to an external server on registration, and receive a certificate for that public key in return. We store the certificate indexed by the credential id, which allows us to find it again at authentication time.

At this point, we end up with a X509Certificate, which provides a java.security.PublicKey. Similar to #288, I am trying to go from there to the COSE_Key required by the library without implementing COSE encoding.

[emlun]

Thanks for the input!

The detour through COSE might actually be an unnecessary indirection in the CredentialRecord interface. The only thing it's used for in the verification procedure is to import the key as a PublicKey... so if the application already has a PublicKey instance it makes much more sense to just pass that directly. So perhaps we should replace the CredentialRecord.getPublicKeyCose(): ByteArray method with just getPublicKey(): PublicKey, and instead provide a helper method or base class to import COSE as a PublicKey.

On the other hand, the most common use case is likely to be that the application simply gets the COSE result from the registration results as opaque binary data and just passes the same binary data back into the assertion procedure, so it's good if we can avoid extra friction and have things "just work" by default for that use case too. For example I'm not too keen on having getPublicKeyCose(): Optional<ByteArray> and getPublicKey(): Optional<PublicKey> both with default no-op implementations, as that would reveal only at runtime that you should implement exactly one of those two. Maybe a default implementation of getPublicKey(): PublicKey that imports from an abstract getPublicKeyCose(): ByteArray would work, although I still don't quite like that you'd be stuck with throwing a runtime UnsupportedOperationException or something in the latter if you choose to instead override the former. But there certainly are ways we could do this.

I'm certainly in favour of the idea, we'll have to think a bit about how best to do it.