Implement EthereumEip712Signature2021 #213
Merged
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.
Implement Ethereum EIP712 Signature 2021.
The Ethereum EIP712 Signature Suite specification is a work item proposal in W3C CCG: w3c-ccg/community#194
This signature suite is like
ssi
's Eip712Method2021 and EthereumPersonalSignature2021, but uses EIP-712 structured data as a data model rather than RDF.A proof option is added, "eip712Domain", for the corresponding proof property from the specification. This is not ideal because it's a breaking change and not standard in
vc-http-api
, but I don't know how else to pass this information currently. Theeip712Domain
object contains the EIP712 type definitions (messageSchema
) as a dereferencable URI or object,domain
object, andprimaryType
string. These three values are meta-data which are combined with the document and proof to create the signing input. After signing, theeip712Domain
object is placed into the proof object along with the signature (proofValue
).Remote loading of type definitions is not implemented currently but some may be bundled in
ssi
. Using the object form ofmessageSchema
may therefore be preferred. However, if a document using EthereumEip712Signature2021 with such form is embedded in another one, e.g. a verifiable presentation, the complexity of the types is increased, since a type definition is needed for the type definitions in the embedded message.A JSON-LD context file is added. Even though this signature suite does not use JSON-LD and the term definitions in the context do not affect signing input, the context file is intended to assist embedding verifiable credentials using this format in verifiable presentations using linked-data-based signature suites. This context file is not from the specification, however.
This signature suite maps currently does not allow arrays of values of different types, so putting objects alongside URIs in
@context
will not work.I was not able to verify the signature from the specification's test vector example 5 (non-normative); more information may be needed to verify it.
LinkedDataDocument
.remote and/orbundled loading of type definitions.TypedData
from LinkedDataDocument, proof, and type definitions.[ ] Verify test vector from specification.Screenshot