Skip to main content
Verifiable credentials on Moca Network are designed to be tamper-evident, privacy-preserving, and portable to any verifier that uses AIR verification.

​
Issuance integrity

When a credential is issued:
  1. The issuer signs the credential data with issuer-controlled keys, bound to their DID. SD-JWT issuers (SD_JWT_VC) publish the verifying keys in a did:web document on their own domain. Holder binding depends on the format:
    • SD-JWT VC. The issuer writes the holder’s signing public key, which AIR supplies on both SDK and direct issuance, to the credential’s cnf claim. The holder proves possession with a key-binding JWT.
    • Iden3. The credential is bound to the holder’s did:air through credentialSubject.id, plus an optional proof in the presentation. There is no cnf claim.
  2. The signed credential payload is encrypted to the holder’s public key.
  3. The encrypted envelope is stored in DStorage. AIR stores and routes opaque ciphertext and metadata as a blind facilitator — it never sees the plaintext.
The issuer’s signature acts as a tamper seal. If the credential data is modified after issuance, any verification will fail because the signature no longer matches.

​
Verification

Verification is program-driven:
  • The verifier asks a question: “Does this user hold a valid credential matching schema X?”
  • The holder decrypts the matching credential and approves the requested disclosure.
  • For SD-JWT credentials, when the verifier sends a nonce, the holder signs a key-binding JWT over the disclosed credential, the verifier’s nonce, and programId, so the presentation cannot be replayed or altered.
  • The verifier receives a compliance result and a Verifiable Presentation containing the disclosed claims — nothing else.
The presentation wrapper is not signed. Verifiers should check the SD-JWT inside it on their own backend: see Verify SD-JWT on your backend.

​
Selective disclosure

Holders can disclose individual attributes without revealing the full credential. How this works depends on the credential format:
  • SD-JWT VC. Each disclosable claim is replaced in the signed credential by a salted digest. The holder sends only the disclosures for the requested claims, and the verifier checks each against its digest. The verifier sees the exact value of each disclosed claim.
  • Iden3. A zero-knowledge proof can establish a condition, such as kycLevel >= 2, without revealing the value. An attribute Merkle root binds the proven fields to the signed credential.
Disclosed claims may still be personal data. Selective disclosure is defined at the schema and verification program level. See Schema Design for configuration.

​
Credential revocation

Issuers revoke credentials from their own issuer service. Verification programs that enable issuer revocation checks reject a revoked credential once the revoked status is published. SD-JWT issuers can also publish an IETF Token Status List, which verifiers cache; revocation then reaches them after the issuer’s publish interval. See Revoke credentials.

​
Credential storage

​
Further reading