Verifiable Credentials

~alter issues W3C Verifiable Credentials that cryptographically prove an individual’s traits, skills, and assessment results. Credentials are portable, tamper-evident, and independently verifiable without contacting ~alter. Credential sharing requires L3 engagement level or above.

Credential types

~alter issues four types of verifiable credentials, each representing a different facet of an individual’s verified identity:

Trait attestationtrait_attestation

Attests trait signals inferred through Discovery. Carries the archetype family and trait-category coverage as bucketed tiers, never raw scores.

Skill verificationskill_verification

Attests a verified skill, backed by the evidence records held against the claim.

Org validationorg_validation

An organisation’s independent validation of an individual’s claim, carried at the org-validated attestation tier.

Assessment completionassessment_completion

Attests that the individual completed ~alter’s Discovery. Contains the archetype label and trait-category summaries (bucketed tiers, never raw scores).

Every credential also carries an attestation tier: self_attested, platform_verified, or org_validated, recording who verified the claim.

Issuance flow

Credentials are issued through a four-step pipeline:

1. 1Discovery

   Individual moves through Discovery. The Recogniser reads each response and chooses what to surface next.

2. 2Extraction

   LLM extracts trait signals from responses. PII is redacted. Raw text is never stored beyond the 90-day retention window.

3. 3Credential generation

   Platform generates a W3C-compliant credential containing the verified claims. Credential ID, subject, issuer, and issuance date are set.

4. 4Signing

   Credential is signed with ~alter’s ES256 private key and issued as a compact attestation token (JWT). The public key is available at the JWKS endpoint for independent verification.

Verification flow

Any party can verify an ~alter credential without contacting the platform directly:

1. 1Present credential

   Individual shares the compact attestation token (JWT) with a verifier.

2. 2Verify signature

   Verifier fetches ~alter’s public key from the JWKS endpoint and validates the ES256 signature.

3. 3Check revocation

   Optionally check the credential’s revocation status via the verification endpoint.

Compact attestation tokens

~alter credentials are issued as ES256-signed JWTs: compact, URL-safe, and independently verifiable. The token contains the credential claims as JWT payload.

// Decoded JWT payload (compact attestation token)
{
  "iss": "did:alter:platform",
  "sub": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "iat": 1741608000,
  "exp": 1773144000,
  "jti": "cred_f47ac10b58cc4372",
  "type": "assessment_completion",
  "claims": {
    "archetype": "Pragmatist",
    "assessment_phase": "complete",
    "trait_categories": {
      "adaptive_capacity": "high",
      "cognitive_style": "high",
      "interpersonal_orientation": "moderate",
      "drive_architecture": "high",
      "integrity_trust": "high"
    },
    "engagement_level": 3
  }
}

JWKS endpoint

~alter’s public signing key is published at a well-known endpoint for independent credential verification:

GET /.well-known/alter-keys.json

{
  "keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "kid": "alter-signing-key-2026",
      "use": "sig",
      "alg": "ES256",
      "x": "f83OJ3D2xF1Bg8vub9tLe...",
      "y": "x_FEzRu9m36HLN_tue659..."
    }
  ]
}

Verifying a credential

Two approaches: stateless JWT verification using the JWKS public key, or server-side verification via the API (which also checks revocation):

import jwt
import requests

# Fetch ~alter's public key
jwks = requests.get(
    "https://mcp.truealter.com/.well-known/alter-keys.json"
).json()
public_key = jwt.algorithms.ECAlgorithm.from_jwk(jwks["keys"][0])

# Verify the compact attestation token
token = "eyJhbGciOiJFUzI1NiIs..."
try:
    claims = jwt.decode(
        token,
        public_key,
        algorithms=["ES256"],
        issuer="did:alter:platform"
    )
    print(f"Valid credential: {claims['type']}")
    print(f"Archetype: {claims['claims']['archetype']}")
except jwt.InvalidTokenError as e:
    print(f"Invalid credential: {e}")

Revocation

Credentials can be revoked by the owning individual or a platform administrator. Revocation is immediate.

JWT validity

The JWT itself remains cryptographically valid after revocation. Signatures do not expire on revocation, so verifiers should check revocation status via the API for high-assurance use cases.

Revocation checkcheck_revocation

The GET /credentials/verify endpoint accepts a check_revocation query parameter (default true) to include revocation status in the response.

Reason required

A revocation reason must be provided, for example “Data no longer accurate” or “Consent withdrawn”.

API endpoints

The following endpoints manage the credential lifecycle (issuance, listing, verification, and revocation):