Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Linked data proof type for signing with Tezos wallets. Like TezosSignature2021 (#170) but not using RDF canonicalization. Instead, uses JCS.
Public key and signature encoding
While TezosSignature2021 includes the public key in the proof object in the publicKeyJwk property, here the public key is instead encoded in a publicKeyMultibase property. The purpose of this is to more closely follow Tezos's native format (e.g.
edpk...
), for easier inspection and verification. Tezos's native key and signature format use base58 with ASCII prefixes. There is a publicKeyBase58 format which used to be defined in DID Core but now has been deprecated in favor of publicKeyMultibase. Fortunately a base58 string can be converted to a multibase string simply by prepending the character "z". So that is the format used here, as seen in the added example VC. publicKeyMultibase is expected to use multicodec, according to Security Vocab, but that doesn't seem to be a hard requirement. A helper function to convert a JWK to a Tezos string is needed here and added in #267.For the signature value (proofValue property), the format is the same as in TezosSignature2021: the
edpk
value. There doesn't seem to be an expected or required type forproofValue
, so this seems okay.Example
Signing request (Temple wallet):
Payload:
Resulting VC: https://github.com/spruceid/ssi/blob/57ca1bfd1e451f75dc3c86e7f8cfa22307d2613e/did-pkh/tests/vc-tz1-jcs.jsonld