Optional_idA unique document ID (Mongo DB ObjectID)
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.
The attestation ID. This is the constan ID that is given to the attestation.
Thesse 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.
Holders are the addresses that have been given the attestation.
Metadata for the attestation for display purposes. Note this should not contain anything sensitive. It may be displayed to verifiers.
The inviteCode is used to add the attestation to the user's wallet. Anyone with the key can query it, so keep this safe and secure.
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.
The type of the attestation (e.g. credential).
Deep copies the object and returns a new instance.
Converts the object to a different NumberType equivalent.
Compares this object's fields to another object's fields for equality. Equality is determined by comparing the JSON representations of the objects.
If normalizeNumberTypes is true, then all number types will be compared as strings (i.e. "1n" === "1" === 1). Else, they will be compared as their native types (i.e. 1n !== 1 !== "1").
OptionalnormalizeNumberTypes: boolean
A unique stringified document ID