I'm imagining the internal structure of this API and seeing some need to add definition.
For example, its common to have switch like code that determines in you are using ES256K, RS256, ES256, etc... or Ed25519Signature2018, RsaSignature2018, EcdsaSecp256k1Signature2019, etc...
I think a layer cake diagram which showed how to register new credential proof "issuers" might be helpful here, while this interface defines an issuer API, I think its likely that many will only use it to issue credentials using specific cryptography or standards. I'd like to be able to see how to do that.
We could of course split each of these services up into additional rest APIs, each of which would look very similar to WebKMS... I'm not sure thats the direction we should take initially though... lots of overhead.
I'm imagining the internal structure of this API and seeing some need to add definition.
For example, its common to have switch like code that determines in you are using ES256K, RS256, ES256, etc... or Ed25519Signature2018, RsaSignature2018, EcdsaSecp256k1Signature2019, etc...
I think a layer cake diagram which showed how to register new credential proof "issuers" might be helpful here, while this interface defines an issuer API, I think its likely that many will only use it to issue credentials using specific cryptography or standards. I'd like to be able to see how to do that.
We could of course split each of these services up into additional rest APIs, each of which would look very similar to WebKMS... I'm not sure thats the direction we should take initially though... lots of overhead.