Verification Requirement

Critically, the validity of a claim must be judged by the verifier. KERI and ACDC provide mechanisms for secure attribution - proving who made the claim - but determining whether the claim is true requires additional verification processes, governance frameworks, and trust decisions by relying parties.

Data Format

ACDC Attribute Section

Within ACDCs, claims are encoded in the attributes section (a field), which can be represented in multiple forms:

Compact Form: A SAID (Self-Addressing Identifier) reference to the attributes block:

{
  "a": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj"
}

Expanded Form: Full attribute details:

{
  "a": {
    "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
    "i": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
    "dt": "2024-01-15T10:30:00.000000+00:00",
    "LEI": "549300ABCDEF123456",
    "personLegalName": "Alice Smith",
    "officialRole": "Chief Executive Officer"
  }
}

Field Structure

Claims within the attributes section follow insertion-ordered field maps, where:

• d: SAID of the attributes block itself
• i: AID of the issuee (subject) when present
• dt: Issuance datetime in ISO-8601 format
• Custom fields: Domain-specific attributes (LEI, personLegalName, etc.)

The additionalProperties: false constraint in ACDC schemas ensures no extra fields can be added beyond those defined in the schema, maintaining structural integrity.

Encoding and Serialization

Claims are serialized using CESR (Composable Event Streaming Representation) encoding, which supports:

• JSON serialization: Human-readable text format
• CBOR serialization: Compact binary format
• MGPK serialization: MessagePack binary format

All serializations maintain insertion order to ensure consistent SAID computation across different representations.

Operations

Claim Creation

Claim creation occurs during ACDC issuance:

1. Schema Selection: Issuer selects appropriate JSON Schema defining claim structure
2. Attribute Population: Issuer populates claim fields with verified data
3. SAID Computation: System computes SAID for attributes block
4. Cryptographic Binding: Issuer signs the complete ACDC containing claims

Selective Disclosure

ACDCs support selective disclosure of claims through:

Compact Disclosure: Revealing only SAIDs without exposing claim values:

{
  "a": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj"
}

Partial Disclosure: Revealing some attributes while keeping others compact:

{
  "a": {
    "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
    "LEI": "549300ABCDEF123456"
  }
}

Full Disclosure: Revealing all claim details when required.

Claim Verification

Verification involves multiple steps:

1. Cryptographic Verification: Validate issuer's signature on the ACDC
2. SAID Verification: Recompute SAIDs to ensure data integrity
3. Schema Validation: Confirm claims conform to declared schema
4. Trust Evaluation: Assess issuer's authority and reputation
5. Temporal Validation: Check issuance dates and expiration
6. Revocation Check: Query TEL (Transaction Event Log) for credential status

Claim Updates

Claims in ACDCs are immutable once issued. Updates require:

• Issuing a new ACDC with updated claims
• Revoking the previous ACDC via TEL
• Maintaining provenance chains through edges

Usage Context

IPEX Protocol Integration

Claims are exchanged using IPEX (Issuance and Presentation Exchange) protocol:

Issuance Exchange: Issuer discloses claims to holder:

Issuer → [ACDC with claims] → Holder

Presentation Exchange: Holder discloses claims to verifier:

Holder → [ACDC with claims] → Verifier

vLEI Ecosystem Claims

In the vLEI (verifiable Legal Entity Identifier) ecosystem, claims include:

Legal Entity Claims:

• LEI (Legal Entity Identifier)
• Legal entity name
• Jurisdiction
• Registration status

Role Claims:

• Person legal name
• Official organizational role
• Engagement context role
• Authorization scope

Claim Chaining

ACDCs support claim chaining through edges, creating directed acyclic graphs (DAGs) of related claims:

{
  "e": {
    "d": "EMsSqaJsthSBA4OINZ1_fxfNVkgEPF-Sg5fq-vXM7Z6b",
    "auth": {
      "n": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
      "s": "EH6ekLjSr8V32WyFbGe1zXjTzFs9PkTYmupJ9H65O14g",
      "o": "I2I"
    }
  }
}

This enables:

• Delegation chains: Authority flowing from root to leaves
• Provenance tracking: Verifiable claim history
• Composite credentials: Multiple related claims forming complete attestations

Self-Asserted Claims

When the issuer and subject are identical, claims are self-asserted. These carry different trust implications:

• Lower initial trust weight
• Useful for bootstrapping identity
• May require additional verification
• Common in self-sovereign identity scenarios

Claim Lifecycle

1. Creation: Issuer generates claims based on verified information
2. Issuance: Claims packaged in ACDC and transmitted to holder
3. Storage: Holder maintains ACDC in secure wallet
4. Presentation: Holder selectively discloses claims to verifiers
5. Verification: Verifiers validate claims cryptographically and contextually
6. Revocation: Issuer may revoke claims via TEL updates
7. Expiration: Claims may have temporal validity constraints

Privacy Considerations

Claim handling must balance:

Verifiability: Claims must be cryptographically verifiable Privacy: Selective disclosure minimizes information leakage Correlation: Multiple presentations of same claims may enable tracking Unlinkability: UUID fields in private ACDCs prevent correlation

Governance and Trust

Claim validity depends on:

Issuer Authority: Does issuer have authority to make this claim? Verification Standards: What identity assurance level was used? Schema Compliance: Does claim conform to agreed schema? Temporal Validity: Is claim still current and not expired? Revocation Status: Has claim been revoked by issuer?

Technical Standards Alignment

KERI/ACDC claims align with:

W3C Verifiable Credentials: Claims as credential subjects eSSIF-Lab Framework: Claims as assertions by parties NIST Digital Identity Guidelines: Claims requiring verification ISO Standards: LEI and other standardized claim formats

Architectural Significance

Claims represent the semantic payload of verifiable credentials, while KERI/ACDC infrastructure provides:

• Cryptographic binding: Claims to issuers via AIDs
• Integrity protection: Claims to SAIDs via content addressing
• Provenance tracking: Claims to history via edges
• Privacy preservation: Claims to selective disclosure via compact forms
• Revocation management: Claims to status via TELs

This separation of semantic content (claims) from cryptographic infrastructure (KERI) enables flexible, secure, and privacy-preserving credential systems that can express arbitrary claims while maintaining strong security guarantees.

Security Considerations

• Claim Validation: Never trust claim values without cryptographic verification of issuer signatures
• Replay Protection: Check issuance timestamps to prevent replay attacks
• Revocation Checking: Always verify current revocation status before accepting claims
• Schema Pinning: Validate against specific schema SAIDs to prevent schema substitution attacks

Interoperability

• W3C VC Compatibility: Map ACDC claims to W3C Verifiable Credential format when needed
• Standard Schemas: Use standardized schemas (like vLEI schemas) for interoperability
• CESR Encoding: Support all CESR serialization formats (JSON, CBOR, MGPK) for broad compatibility