Optional
anchorsThesse are the attestations that are signed. For BBS+ signatures, there can be >1 attestationMessages, and the signer can selectively disclose the attestations. For standard signatures, there is only 1 attestationMessage.
When the attestation was created.
The address of the user who created the attestation.
This is the signature and accompanying details of the attestationMessages. The siganture maintains the integrity of the attestationMessages.
This should match the expected scheme. For example, if the scheme is BBS+, the signature should be a BBS+ signature and signer should be a BBS+ public key.
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
Optional
entropiesEntropies used for certain data integrity proofs on-chain (e.g. HASH(message + entropy) = on-chain value)
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
The message format of the attestationMessages.
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
Proof of issuance is used for BBS+ signatures (scheme = bbs) only. BBS+ signatures are signed with a BBS+ key pair, but you would often want the issuer to be a native address. The prooofOfIssuance establishes a link saying that "I am the issuer of this attestation signed with BBS+ key pair ___".
Fields can be left blank for standard signatures.
The scheme of the attestation. BBS+ signatures are supported and can be used where selective disclosure is a requirement. Otherwise, you can simply use your native blockchain's signature scheme.
Optional
update
Anchors are on-chain transactions used to prove certain things about the attestation. For example, you can anchor the attestation to a transaction hash to prove that the attestation existed at a certain time.