Skip to main content
A Credential is a signed attestation issued to a subject. It is the canonical object used by authenticators to generate World ID proofs. Relying parties (RPs) do not receive the credential itself; they verify proofs derived from it. This page documents the Credential object as defined in world-id-protocol, plus PoH-specific conventions from the issuer credential structure spec.
The refresh endpoint returns a base64-encoded Credential. See Credential Issuance for issuance details.

Encoding

Credentials are serialized as JSON and commonly wrapped in base64 when returned by API endpoints.
const decoded = JSON.parse(Buffer.from(credential, "base64").toString("utf8"));

Credential schema

{
  "id": 123456789,
  "version": "V1",
  "issuer_schema_id": 42,
  "sub": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "genesis_issued_at": 1733241600,
  "expires_at": 1764777600,
  "claims": [
    "0x0000000000000000000000000000000000000000000000000000000000000000"
  ],
  "associated_data_hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "signature": "5f2e...a3c1",
  "issuer": {
    "pk": ["1234567890", "9876543210"]
  }
}
The claims array is fixed-length (16 entries) and padded with the zero field element. The example above is shortened for readability.

Field definitions

FieldTypeDescription
iduint64Issuer-scoped reference identifier. Not exposed to RPs.
versionstringCredential version. Current value is V1.
issuer_schema_iduint64Identifier for the (issuer, schema) pair registered in CredentialSchemaIssuerRegistry.
subFieldElementBlinded subject identifier derived from a World ID leaf index and an issuer-specific blinding factor.
genesis_issued_atuint64Unix timestamp (seconds) of the first issuance of this credential.
expires_atuint64Unix timestamp (seconds) for expiration.
claimsFieldElement[]Up to 16 claim commitments. Unused indices are the zero field element.
associated_data_hashFieldElementPoseidon2 hash of issuer-defined associated data. The data itself is not included.
signaturestring64-byte compressed EdDSA signature over the credential hash, hex-encoded (no 0x prefix).
issuerEdDSAPublicKeyIssuer public key that signed the credential.
Claims are included for issuer-defined semantics and may not be enforced by proofs today. Associated data is stored by authenticators and is not exposed to RPs.

Field representations

  • FieldElement values (sub, claims, associated_data_hash) are hex strings with a 0x prefix and 64 hex characters.
  • Issuer public key (issuer.pk) is serialized as [x, y] decimal strings for BabyJubJub affine coordinates.
  • Signature is hex-encoded compressed bytes (128 hex chars).

Hashing and signing

Credentials are hashed with Poseidon2 and signed using EdDSA over the BabyJubJub curve (V1).
claims_hash = Poseidon2_t16(claims[0..15])
cred_hash = Poseidon2_t8(
  DS,
  issuer_schema_id,
  sub,
  genesis_issued_at,
  expires_at,
  claims_hash,
  associated_data_hash,
  id
)
signature = EdDSA_BJJ.sign(cred_hash)
sub is computed by hashing the World ID leaf index with a blinding factor:
sub = Poseidon2_t3(DS_SUB, leaf_index, blinding_factor)

How credentials are used in proofs

When an authenticator generates a proof, it includes the credential and enforces:
  • The credential signature matches the issuer key registered in CredentialSchemaIssuerRegistry.
  • The credential sub matches the blinded leaf index for the holder.
  • The credential is not expired and meets any minimum genesis_issued_at constraints.
This makes credentials portable across authenticators while keeping subjects unlinkable between issuers.

PoH credential usage

Proof-of-Human (PoH) credentials follow the issuer-defined structure. The current PoH issuer spec states:
  • The user first obtains an Orb credential (currently a PCP in v2.3 format).
  • claim[0] is a commitment to the Orb credential, currently H(hashes.json).
  • The PoH credential has no associated data, so associated_data_hash is the zero field element.
  • The PoH credential subject is blinded and differs from the Orb credential subject.
  • The issuer may require a proof for the requested sub to prevent bricking an identity.
These details are issuer-specific and may evolve as the protocol migrates to the World ID 4.0 credential format.

References