An employer receives a wallet badge that claims its holder completed a safety course. The chain can show which address holds the token and which issuer assigned it, but it cannot by itself prove who controls the address, whether that person completed the course, or whether the credential is current. Membership, reputation, and professional claims therefore need an identity system around the token, not merely a public badge.
Identity systems need more than ownership records. They need credible issuers, defined subjects, privacy boundaries, expiration and revocation, recovery, and a verification policy. In many cases a verifiable credential stored by the holder is a better fit than a permanently public NFT because the holder can present selected information without placing the entire claim and activity trail on a public ledger.
What you will learn
- Distinguish a token ownership record from an issuer's claim about a person or organization
- Compare transferable, non-transferable, and holder-presented credential designs
- Evaluate issuer trust, privacy, revocation, recovery, metadata, and verifier responsibilities
A credential is an issuer's claim
A token contract can prove that an authorized address minted or assigned a token and that another address currently holds it. The social meaning comes from the issuer: a university can assert course completion, an association can assert membership, or an unknown wallet can make the same-looking assertion without credibility. Verification must ask who the issuer is trusted to speak for and how its signing authority is governed.
The address holding a token may be controlled by a person, company, custodian, shared wallet, or attacker. Connecting it to a legal or social identity requires an enrollment process and continuing account controls. Even then, verification of a signature or token only shows that the system's rules were followed; it does not independently confirm that the underlying claim was accurate when issued.
Transferability can defeat the purpose
A transferable achievement token can be sold to someone who did not earn it. Non-transferable designs, sometimes called soulbound tokens, can block ordinary transfer and better preserve the link created during issuance. ERC-5192 describes a minimal way for an ERC-721 token to signal that it is locked, but it does not define identity proofing, privacy, revocation, or recovery.
Non-transferability creates its own difficulty when keys are lost, organizations change wallets, or credentials were issued incorrectly. An issuer may need a controlled reissue and revocation process. If an administrator can move or replace tokens, the credential is not independent of that administrator. That may be appropriate, but the authority and evidence requirements should be explicit rather than hidden behind permanent-sounding language.
Public metadata creates durable privacy exposure
Putting names, birth dates, medical information, addresses, or detailed affiliations in public token metadata can expose subjects to profiling and unwanted correlation. Encryption does not solve every problem because ciphertext remains public, keys can later leak, and transaction patterns reveal relationships. Content-addressed storage can make sensitive data harder to retract because copies may persist outside the issuer's control.
Data minimization starts with the verifier's actual need. A venue may need proof that a person meets an age threshold, not a birth date; an employer may need current certification, not every prior job. Holder-controlled presentations and selective-disclosure methods can reduce exposure. The design must still explain linkability, consent, retention, and what information a verifier stores after checking a proof.
Status, recovery, and policy complete verification
Real credentials expire, change, and are revoked. A verifier should check current status through a mechanism designed to avoid unnecessary tracking of the holder. It should also confirm the relevant schema and assurance level: a self-asserted profile token is not equivalent to a government credential, and a training attendance badge is not a professional license.
Recovery should preserve both security and continuity. Automatically accepting any wallet migration request invites impersonation, while refusing all recovery punishes ordinary key loss. Issuers can use documented identity checks, delays, notifications, and revocation of replaced credentials. Governing terms should allocate responsibilities without claiming that code resolves every identity dispute or jurisdictional requirement.
Common misconceptions
“An identity NFT proves the wallet holder is the named person.”
It proves only the token state and authorized actions. Identity assurance depends on issuer enrollment, key control, recovery, status, and verifier policy.
“Identity credentials should be tradable so users truly own them.”
Trading can destroy the meaning of qualifications or membership. User agency is better supported through consent, portability, selective disclosure, and fair recovery than indiscriminate transferability.
“Verification means the underlying claim is definitely true.”
Cryptographic verification establishes integrity, issuer authorization, and possibly status. A verifier must still decide whether it trusts the issuer and evidence for the claimed purpose.
Risks and limitations
- Public identity metadata can enable permanent correlation, discrimination, harassment, or exposure of sensitive affiliations.
- A stolen wallet can let an attacker present a valid token unless verifiers and issuers have effective status and recovery controls.
- Transferable credentials can be purchased by unqualified people, while rigid non-transferability can make legitimate recovery impossible.
- A compromised or careless issuer can create false credentials that remain technically valid until status systems respond.
Key takeaways
- Treat identity as an issuer claim, not a property inferred from token ownership.
- Choose transfer rules based on credential meaning and recovery needs.
- Keep sensitive personal data off public metadata whenever possible.
- Check issuer authority, schema, current status, and assurance level.
- Use holder-controlled and selective-disclosure designs when public tokens are unnecessary.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.