Currently the OpenID4CI and OpenID4VP APIs are designed differently in terms of what they need as input parameters to accomplish JWT signing.
For the OpenID4CI API, the current design requires the caller to specify how to map from a DID verification method object all the way to a signing function (essentially mapping to the key ID in the process). We provide an implementation that uses the Aries crypto+KMS+key mapping behaviour (intended for demo purposes). For production usage, we expect the mobile implementations to inject in their implementation.
For the OpenID4VP API, it directly requires a key ID + signer, and leaves the job of determining the key ID up to the caller.
We should make both APIs more similar, since they do similar things.
To do this, we can:
Change the OpenID4CI API to match more closely the OpenID4VP one.
Add a helper function to the wallet-sdk API that allows a caller to derive the key ID from a DID doc - OR - bake this functionality into the CI and VP APIs, and make a DID an input parameter (so the API methods will do it for the caller). Note that in this case, we must make an assumption about KMS key IDs being derivable from DID docs, and so this should be documented accordingly.
vkubiv
commented
1 year ago
Currently the OpenID4CI and OpenID4VP APIs are designed differently in terms of what they need as input parameters to accomplish JWT signing.
For the OpenID4CI API, the current design requires the caller to specify how to map from a DID verification method object all the way to a signing function (essentially mapping to the key ID in the process). We provide an implementation that uses the Aries crypto+KMS+key mapping behaviour (intended for demo purposes). For production usage, we expect the mobile implementations to inject in their implementation.
For the OpenID4VP API, it directly requires a key ID + signer, and leaves the job of determining the key ID up to the caller.
We should make both APIs more similar, since they do similar things.
To do this, we can:
Change the OpenID4CI API to match more closely the OpenID4VP one. Add a helper function to the wallet-sdk API that allows a caller to derive the key ID from a DID doc - OR - bake this functionality into the CI and VP APIs, and make a DID an input parameter (so the API methods will do it for the caller). Note that in this case, we must make an assumption about KMS key IDs being derivable from DID docs, and so this should be documented accordingly.