A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified.
A credential contains claims about a subject made by the issuer. Both subject and issuer are identified through a DID. Verifying a claim required resolving the DID of the issuer to validate the signatures (proofs) of the credential.
Issuing credentials doesn't require the use of a blockchain. Cryptographic signatures of the claims are embedded within the credential. Blockchain can be used to add a layer of security. A validator might require on-chain proof to prevent issuers from backdating credentials.
The LTO network address of the subject and a base58 encoded sha256 hash of the credential is used to create a DID URL.
prooffields should be omitted when creating the hash.
- The sender is the account that corresponds with a DID verification method of the issuer.
- The association type for a verifiable credential is
- The hash field contains the credential hash. It must be same hash as used to create the DID URL.
To revoke a credential, simply revoke the association. The revocation timestamp is determined by the timestamp of the block, rather than the timestamp of the transaction.
If the issuer didn't publish an association for the credential, it can issue a dispute (type
0x12) instead. A dispute by the issuer is interpreted as a revocation.
The issuer is able to suspend a credential through an association with type
0x11. The association can be revoked to unsuspend the credential.
The association recipient is the address from the DID of the subject. The association hash must be taken from the credential status id.
By default, only the issuer can suspend a credential. It's possible to allow other parties to suspend associations through the trust network configuration.
Anyone can dispute the claims of a credential. This is done through an association with type
0x12. The dispute can also be revoked.
For a dispute, the association recipient is the address from the DID of the subject. The association hash must be taken from the credential status id.
By default, the identity node will only index claims from accounts within the configured trust network.