Issue, accept, revoke

A credential has a short life with three moves.

1. The issuer creates it. The issuer writes a credential for your account. At this point it is only an offer. It does not count yet.

2. You accept it. You send a transaction that says yes. Now the credential is valid.

Why the extra step? So nobody can pin a label on your account without your say. An unaccepted credential proves nothing about you.

3. Someone deletes it. Either side can end it at any time.

• The issuer deletes it to revoke it. Maybe your check went stale.
• You delete it because you no longer want it.

A credential can also carry an end date. After that date it is expired. An expired credential stops counting, and then anyone can delete it.

Who pays the reserve? Each credential is one item on the ledger, so it locks 0.2 XRP today.

• Before you accept: the issuer's account holds that reserve.
• After you accept: your account holds it.

So accepting a credential costs you a small locked amount. Deleting it unlocks that.

You can hold many credentials, from many issuers. You can hold several from one issuer, as long as each has a different type. One issuer, one subject and one type make exactly one credential.

CredentialCreate, sent by the issuer:

Results: tecDUPLICATE if the same subject, issuer and type already exist. tecEXPIRED if Expiration is in the past. tecNO_TARGET if the subject is not a funded account.

CredentialAccept, sent by the subject, names Issuer and CredentialType. It sets the lsfAccepted flag (0x00010000) on the entry.

• tecNO_ENTRY: no such credential.
• tecDUPLICATE: already accepted.
• tecEXPIRED: the credential has expired. The transaction also deletes it.

CredentialDelete names CredentialType plus Subject, Issuer or both. An omitted one defaults to the sender. The issuer or the subject can delete at any time. If the credential is expired, anyone can. Otherwise a third party gets tecNO_PERMISSION.

The entry. A Credential is linked from both the subject's and the issuer's directories. Its ID is a hash of the space key 0x0044, the subject, the issuer and the credential type. That makes each triple unique.

Reserve. One item toward the subject's owner reserve if lsfAccepted is set. Otherwise one item toward the issuer's.

Account deletion. A Credential is not a deletion blocker. If the subject or the issuer deletes its account, the entry is deleted with it.

Verifying. xrpl.org's tutorial gives three checks:

1. Fetch the entry with ledger_entry from the latest validated ledger. Pass credential as an object with subject, issuer and credential_type. An entryNotFound error means it does not exist or was deleted.
2. Test the lsfAccepted bit in Flags.
3. If Expiration is present, compare it with the close time of the previous ledger. With no Expiration, the credential stays valid indefinitely.

A credential that passes all three is valid. Whether its issuer deserves trust is a separate question that the ledger does not answer.

Related: Owner reserve, Getting reserves back.