Key participants in compact disclosure include:

• Discloser: The entity presenting the compact ACDC, typically the credential holder
• Disclosee: The entity receiving the compact disclosure, typically a verifier
• Issuer: The original credential issuer whose signature commits to all variants (compact and expanded)

Process Flow

Step 1: ACDC Structure Preparation

The compact disclosure process begins with a fully structured ACDC containing multiple field maps (sections). According to Document 3, an ACDC consists of:

• Top-level fields: Version (v), SAID (d), Issuer AID (i), Registry ID (ri)
• Schema section (s): Can be a SAID or full schema
• Attributes section (a): Can be a SAID or full attribute block
• Edges section (e): Can be a SAID or full edge block
• Rules section (r): Can be a SAID or full rule block

Each section that supports compact disclosure has two possible representations:

1. Full form: The complete field map with all data
2. Compact form: Just the SAID of that field map

Step 2: SAID Computation for Field Maps

For each field map that will be compacted, a SAID must be computed. Document 7 demonstrates this process:

H(a) = H(
  b = N,
  c = H(c),  # recurse
  g = Q,
  i = H(i)   # recurse
) = SAID

The SAID computation is recursive: nested field maps are first replaced by their own SAIDs before computing the parent SAID. This creates a hash tree structure where:

• Leaf nodes are primitive values
• Internal nodes are SAIDs of nested structures
• The root is the top-level ACDC SAID

Critical property: The SAID computation produces identical results whether computed from the fully expanded form or the partially compact form, as demonstrated in Document 7:

Fully Expanded:     H(b=N, c=H(d=M, e=O, f=P), g=Q, i=H(j=R, k=S)) = SAID
Partially Compact:  H(b=N, c=H(c), g=Q, i=H(i)) = SAID
Fully Compact:      H(a) = SAID

All three representations produce the same SAID, ensuring cryptographic equivalence.

Step 3: Compact Variant Construction

The Discloser constructs the compact variant by replacing selected field maps with their SAIDs. Document 3 specifies that the value of a top-level section field can be either:

• The SAD (Self-Addressed Data) - the full field map
• The SAID of the SAD - just the cryptographic commitment

For example, a fully expanded ACDC might have:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": {
    "$id": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {...}
  },
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDI",
    "dt": "2024-01-15T10:30:00Z",
    "LEI": "254900OPPU84GM83MG36"
  }
}

The compact variant replaces the full attribute block with its SAID:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY"
}

Step 4: Signature Verification

Document 3 establishes a critical property: An Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants.

This means:

1. The Issuer signs the fully compact or most compact variant
2. This signature cryptographically commits to the top-level SAIDs
3. The signature remains valid for all variants (compact, partial, full) because they share the same top-level structure
4. Verifiers can validate the compact form without needing the full content

The verification process:

1. Extract Issuer AID from compact ACDC
2. Retrieve Issuer's current public key from KEL
3. Verify signature on compact ACDC
4. Confirm top-level SAID matches computed digest
5. Accept compact disclosure as valid

Step 5: Optional Expansion and Re-verification

When the Discloser later provides expanded content, the Disclosee can verify consistency:

1. Receive expanded field map (e.g., full attributes block)
2. Compute SAID of expanded content
3. Compare computed SAID to previously disclosed SAID
4. If match: expanded content is authentic
5. If mismatch: reject as tampered or incorrect

Document 7 demonstrates this property: "The recipient can verify the expansion is authentic by recomputing the SAID and confirming it matches the original compact representation."

Technical Requirements

Cryptographic Requirements

SAID Algorithm Consistency: All SAIDs within an ACDC must use consistent cryptographic hash functions. Document 3 specifies that SAIDs must provide approximately 128 bits of cryptographic strength.

Canonical Serialization: Document 3 mandates insertion-ordered field maps for canonical serialization. This requirement is critical because:

• The same logical content must always serialize identically
• SAID computation depends on deterministic serialization
• Different field orderings would produce different SAIDs, breaking verification

Signature Binding: The Issuer's signature must bind to the compact variant's top-level structure. Document 12 explains: "The signature on the compact form provides integrity proof for the entire tree."

Recursive SAID Computation: Nested structures require recursive SAID computation where inner SAIDs are computed before outer SAIDs, as shown in Document 7.

Timing Considerations

Pre-computation: SAIDs should be computed during credential issuance, not during disclosure. This ensures:

• Consistent SAIDs across all presentations
• Faster disclosure operations
• No risk of computation errors during time-sensitive exchanges

Caching: Implementations should cache computed SAIDs to avoid redundant hash operations. Document 3 notes that SAID computation can be computationally intensive for large structures.

Verification Latency: Compact disclosure verification is faster than full disclosure because:

• Smaller data payloads to transmit
• Fewer fields to parse
• Signature verification on compact structure is identical cost

Error Handling

SAID Mismatch: If an expanded field map's computed SAID doesn't match the previously disclosed SAID:

ERROR: SAID mismatch detected
Expected: EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY
Computed: EXyzABC123...
Action: Reject expanded content as invalid

Missing SAIDs: If a compact ACDC references a SAID that cannot be resolved:

ERROR: Unresolvable SAID reference
SAID: EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY
Action: Request full disclosure or reject credential

Signature Verification Failure: If the Issuer's signature doesn't verify on the compact form:

ERROR: Invalid Issuer signature
Issuer AID: did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM
Action: Reject credential as unverifiable

Usage Patterns

Pattern 1: Initial Low-Trust Interaction

Scenario: A credential holder presents proof of credential possession without revealing details.

Implementation:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
  "e": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
}

Benefits:

• Verifier confirms credential exists and is validly signed
• Holder reveals no personal information
• Establishes basis for further negotiation

Pattern 2: Chained Credential References

Scenario: An ACDC references another ACDC through an edge without exposing the referenced credential's content.

Document 57 demonstrates this pattern in vLEI credentials:

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

The n field contains the SAID of the authorization credential, creating a verifiable chain without exposing the authorization credential's content.

Pattern 3: Progressive Disclosure Workflow

Scenario: Multi-stage credential presentation with increasing disclosure levels.

Stage 1 - Compact Disclosure:

{"a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY"}

Stage 2 - Partial Disclosure (after agreement to terms):

{
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDI",
    "dt": "2024-01-15T10:30:00Z",
    "personal": "EXyzABC123..."
  }
}

Stage 3 - Full Disclosure (after contractual protections):

{
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDI",
    "dt": "2024-01-15T10:30:00Z",
    "personal": {
      "legalName": "Alice Smith",
      "birthDate": "1990-05-15"
    }
  }
}

Pattern 4: Schema Compaction

Scenario: Large schema definitions that don't need to be transmitted repeatedly.

Document 3 shows that schemas can be compacted:

{
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A"
}

Verifiers can:

1. Recognize the schema SAID
2. Retrieve the full schema from a registry or cache
3. Validate the ACDC against the schema
4. Avoid repeated transmission of large schema definitions

Best Practices

1. Compute SAIDs at Issuance: Pre-compute all SAIDs during credential creation to ensure consistency and avoid runtime errors.

2. Maintain SAID Registries: Implement registries or caches where full content can be retrieved by SAID, enabling efficient expansion when needed.

3. Use Compact Forms for Initial Presentations: Start with compact disclosure and progressively expand based on verifier requirements and trust development.

4. Validate Expansions: Always verify that expanded content matches the previously disclosed SAID before accepting it as authentic.

5. Document Disclosure Policies: Clearly specify which fields support compact disclosure and under what conditions they will be expanded.

Integration Considerations

IPEX Protocol Integration: Document 14 specifies that compact disclosure integrates with IPEX (Issuance and Presentation Exchange) for credential exchanges:

Discloser -> [Compact ACDC] -> Disclosee
Disclosee -> [Request Expansion] -> Discloser
Discloser -> [Expanded Content] -> Disclosee

KEL Anchoring: Compact ACDCs must be anchored to the Issuer's KEL (Key Event Log) to enable signature verification. Document 3 notes that the Issuer AID field (i) references the KEL for key state lookup.

TEL Integration: Document 23 explains that Transaction Event Logs (TELs) track credential status (issuance/revocation). Compact ACDCs reference TELs through the registry identifier (ri) field.

Storage Optimization: Compact forms significantly reduce storage requirements. Document 12 notes that compact ACDCs can be 10-100x smaller than fully expanded forms, depending on attribute complexity.

Relationship to Other Disclosure Mechanisms

Compact disclosure serves as the foundation for two other disclosure mechanisms:

Partial Disclosure: Document 2 defines partial disclosure as "a disclosure of an ACDC that partially discloses its field maps using Compact Disclosure." Partial disclosure builds on compact disclosure by:

• Revealing some field maps in full
• Keeping others as SAIDs (compact)
• Enabling mixed disclosure levels within a single ACDC

Selective Disclosure: Document 4 defines selective disclosure as using "Compact Disclosure with an array of blinded blocks." Selective disclosure extends compact disclosure by:

• Creating separate blinded blocks for each selectively disclosable attribute
• Using SAIDs to represent undisclosed attributes
• Preventing correlation between disclosed and undisclosed attributes

Both mechanisms rely on compact disclosure's core property: representing field maps by their SAIDs provides cryptographic commitments without revealing content.

Security Considerations

Rainbow Table Attacks: Document 36 warns that compact disclosure alone may be vulnerable to rainbow table attacks if attribute values are predictable. The solution is to include UUID fields (u) that add high-entropy nonces, making pre-computation attacks infeasible.

Correlation Risks: Compact disclosure of the same SAID across multiple presentations creates correlation opportunities. Document 9 recommends using selective disclosure when correlation resistance is required.

Timing Attacks: SAID computation timing may leak information about content size or complexity. Implementations should use constant-time operations where possible.

Signature Verification: Always verify the Issuer's signature on compact forms before trusting the SAIDs. A valid signature proves the Issuer committed to those specific SAIDs, preventing substitution attacks.

1. Add UUID Fields: Include high-entropy UUID fields (u) in ACDCs to prevent rainbow table attacks on predictable attribute values.

2. Avoid SAID Reuse: Don't disclose the same SAID across multiple contexts if correlation resistance is required. Use selective disclosure instead.

3. Timing Attacks: Use constant-time operations for SAID computation where possible to prevent timing-based information leakage.

Integration Points

1. IPEX Protocol: Compact disclosure integrates with IPEX for credential exchanges. Implement request/response flows for progressive expansion.

2. TEL References: Compact ACDCs reference Transaction Event Logs (TELs) through the registry identifier (ri) field for credential status checking.

3. Schema Validation: Validate compact ACDCs against their schemas even when attributes are compacted. The schema SAID (s) enables schema lookup and validation.

Performance Optimization

1. Lazy Expansion: Only expand compact field maps when explicitly requested by verifiers. Keep compact forms in memory/storage.

2. Batch SAID Computation: When issuing multiple credentials, batch SAID computations to amortize cryptographic operation costs.

3. Parallel Verification: Signature verification and SAID computation can be parallelized for ACDCs with multiple compact sections.

Testing Requirements

1. Round-Trip Testing: Verify that compact -> expand -> compact cycles produce identical SAIDs.

2. Cross-Variant Testing: Ensure signatures verify correctly on compact, partial, and full variants of the same ACDC.

3. Expansion Validation: Test that expanded content always matches its compact SAID representation.

4. Error Case Testing: Verify proper handling of SAID mismatches, signature failures, and missing SAID references.