All of our apis support wrapping operations in verifiable credentials. However, the syntax we use for our operations is not valid json-ld, so the keys are dropped when hashing, making the signature worthless.
In order to properly expand the operations we need to define a context that will properly handle the operation.
Possible approaches:
1: Just wrap everything under a single key with @type@json
This has the advantage of simplifying parsing at the expense of extra verbosity (the additional wrapping). Users can still use default context just fine.
2: Make every operation's top-level keys @type@json
Explicit context required
Both approaches require including an @context key inside the operation in order for credential verification to work properly. If the @context key is not inside the credential and we use it as a hidden input to the verification step, we are not following the EcdsaSecp256k1RecoverySignature2020 proof spec, and other people will not be able to validate our credentials.
All of our apis support wrapping operations in verifiable credentials. However, the syntax we use for our operations is not valid json-ld, so the keys are dropped when hashing, making the signature worthless.
In order to properly expand the operations we need to define a context that will properly handle the operation.
Possible approaches:
1: Just wrap everything under a single key with
@type@jsonThis has the advantage of simplifying parsing at the expense of extra verbosity (the additional wrapping). Users can still use default context just fine.
2: Make every operation's top-level keys
@type@jsonExplicit context required Both approaches require including an
@contextkey inside the operation in order for credential verification to work properly. If the@contextkey is not inside the credential and we use it as a hidden input to the verification step, we are not following theEcdsaSecp256k1RecoverySignature2020proof spec, and other people will not be able to validate our credentials.