Disclosee: The verifying entity that receives the partially disclosed ACDC. The Disclosee can cryptographically verify that disclosed field maps match their SAID commitments in the compact form, ensuring the disclosed content is authentic and unaltered.

Process Flow

Step 1: Credential Issuance with Nested Structure

The Issuer creates an ACDC with a hierarchical attribute structure designed for partial disclosure:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "publicInfo": {
      "name": "Alice Smith",
      "country": "USA"
    },
    "sensitiveInfo": {
      "d": "EH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
      "ssn": "123-45-6789",
      "dateOfBirth": "1990-01-15"
    }
  }
}

The Issuer computes SAIDs for each nested field map recursively, creating a compact variant where sensitiveInfo is replaced by its SAID.

Step 2: Compact Variant Creation

The Issuer creates a compact variant by replacing nested field maps with their SAIDs:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "publicInfo": {
      "name": "Alice Smith",
      "country": "USA"
    },
    "sensitiveInfo": "EH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
  }
}

The Issuer signs this compact variant and anchors the signature in a Transaction Event Log (TEL), creating a cryptographic commitment to both the disclosed and undisclosed field maps.

Step 3: Initial Presentation with Partial Disclosure

When presenting the credential, the Discloser provides the compact variant initially:

• The publicInfo field map is fully disclosed
• The sensitiveInfo field map is represented only by its SAID
• The Disclosee can verify the ACDC signature and SAID integrity
• The Disclosee knows that additional information exists (the sensitiveInfo field) but cannot access its contents

Step 4: Progressive Disclosure Decision

Based on the interaction context, the Discloser decides whether to reveal additional field maps:

Scenario A - No Further Disclosure: If the Disclosee's requirements are satisfied with the public information, the interaction completes without revealing sensitiveInfo.

Scenario B - Conditional Disclosure: The Discloser may require the Disclosee to agree to contractual terms (via chain-link confidentiality) before revealing sensitiveInfo.

Scenario C - Full Disclosure: After contractual agreements are established, the Discloser provides the full field map:

{
  "d": "EH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
  "ssn": "123-45-6789",
  "dateOfBirth": "1990-01-15"
}

Step 5: Verification of Disclosed Content

The Disclosee verifies the newly disclosed field map:

1. SAID Computation: Compute the SAID of the disclosed field map
2. SAID Matching: Verify it matches the SAID in the compact variant (EH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA)
3. Signature Verification: Confirm the Issuer's signature on the compact variant remains valid
4. Integrity Confirmation: The disclosed content is proven authentic and unaltered since issuance

Technical Requirements

Cryptographic Requirements

SAID Protocol Compliance: All field maps subject to partial disclosure must be SADs (Self-Addressed Data structures) with properly computed SAIDs. The SAID computation must follow the recursive algorithm:

H(field_map) = H(
  field1 = value1,
  field2 = value2,
  nested_map = H(nested_map)  # Recurse for nested structures
)

Cryptographic Binding: The Issuer's signature on the compact variant creates a cryptographic commitment to all field maps, whether disclosed or compact. This binding ensures that:

• Disclosed field maps cannot be altered without detection
• The relationship between compact SAIDs and their underlying content is verifiable
• The Issuer cannot repudiate the content of undisclosed field maps

Hash Function Requirements: The hash function used for SAID computation must be:

• Collision-resistant (computationally infeasible to find two inputs producing the same SAID)
• Pre-image resistant (computationally infeasible to derive the input from the SAID)
• Second pre-image resistant (computationally infeasible to find a different input producing the same SAID)

KERI typically uses Blake3 or SHA-256 for SAID computation, both providing 256-bit security.

Structural Requirements

Nested Field Map Architecture: The ACDC attribute section must be structured as a tree where:

• Each node is a field map (key-value mapping)
• Leaf nodes contain primitive values (strings, numbers, booleans)
• Internal nodes contain nested field maps
• Each field map has a d field containing its SAID

Insertion-Ordered Field Maps: ACDC requires insertion-ordered field maps for canonical serialization. This ensures:

• Reproducible SAID computation across implementations
• Consistent serialization for signature verification
• Deterministic round-trip conversion between compact and expanded forms

Schema Compliance: The ACDC schema must support both compact and expanded variants using JSON Schema composition operators:

{
  "oneOf": [
    {"type": "string"},  // Compact form (SAID)
    {"type": "object"}   // Expanded form (field map)
  ]
}

Timing Considerations

Asynchronous Disclosure: Partial disclosure supports asynchronous revelation of field maps:

• Initial presentation may occur at time T₀
• Additional field maps may be disclosed at times T₁, T₂, ... Tₙ
• Each disclosure step is independently verifiable
• No time constraints exist between disclosure steps

Credential Lifecycle: Partial disclosure must account for credential status:

• Issuance State: Verify the credential is issued (TEL shows issuance event)
• Revocation State: Check the credential has not been revoked before accepting disclosed field maps
• Expiration: Respect any temporal validity constraints in the credential

Error Handling

SAID Mismatch: If a disclosed field map's computed SAID does not match the SAID in the compact variant:

• Action: Reject the disclosed field map as invalid
• Cause: Either the field map was altered, or the wrong field map was provided
• Security Implication: Potential tampering or substitution attack

Missing Field Maps: If a Discloser cannot provide a field map for a SAID in the compact variant:

• Action: The disclosure remains valid for the field maps that were provided
• Limitation: The Disclosee cannot verify the missing field map's contents
• Use Case: Legitimate when the Discloser chooses not to reveal certain field maps

Schema Validation Failure: If a disclosed field map does not conform to the ACDC schema:

• Action: Reject the disclosure as malformed
• Cause: Implementation error or schema mismatch
• Resolution: Verify schema compatibility between Issuer and Discloser

Usage Patterns

Typical Scenarios

Scenario 1: Progressive Trust Building

A credential holder presents a professional credential to a potential employer:

1. Initial Contact: Disclose only name, professional title, and general qualifications
2. Interview Stage: After establishing mutual interest, disclose education details and certifications
3. Offer Stage: After receiving a job offer, disclose employment history and references
4. Onboarding: After accepting the offer, disclose sensitive information like tax identification

Each stage reveals additional field maps based on the evolving trust relationship and contractual commitments.

Scenario 2: Regulatory Compliance

A financial institution verifies customer credentials for KYC (Know Your Customer) compliance:

1. Public Verification: Customer discloses name and country of residence
2. Risk Assessment: Based on risk profile, institution requests additional field maps
3. Enhanced Due Diligence: For high-risk customers, full disclosure of all field maps is required
4. Ongoing Monitoring: Periodic re-verification may request specific field maps

Partial disclosure enables risk-based verification where disclosure depth matches regulatory requirements.

Scenario 3: Supply Chain Transparency

A product credential tracks manufacturing and distribution:

1. Consumer View: Disclose product name, manufacturer, and sustainability certifications
2. Retailer View: Disclose wholesale pricing and inventory management data
3. Regulator View: Disclose complete manufacturing process, ingredient sourcing, and quality control records
4. Auditor View: Full disclosure of all field maps for compliance verification

Different stakeholders receive different disclosure levels based on their role and need-to-know.

Best Practices

Design for Disclosure Granularity: When creating ACDC schemas, structure the attribute tree to align with expected disclosure patterns:

• Group related attributes into nested field maps
• Separate public information from sensitive information
• Create field map boundaries at natural disclosure decision points
• Avoid overly deep nesting that complicates disclosure decisions

Implement Disclosure Policies: Establish clear policies for when to disclose field maps:

• Define disclosure levels (public, restricted, confidential, secret)
• Map field maps to disclosure levels
• Require contractual agreements before disclosing restricted/confidential field maps
• Log disclosure events for audit trails

Leverage Contractual Protections: Combine partial disclosure with contractually protected disclosure:

• Present schema information before disclosing field maps
• Require Disclosee agreement to Ricardian contracts governing data use
• Implement chain-link confidentiality to bind downstream recipients
• Establish legal recourse for misuse of disclosed information

Optimize for Common Cases: Design disclosure strategies for typical use cases:

• Make frequently disclosed field maps easily accessible
• Cache compact variants to avoid recomputation
• Pre-compute SAIDs for all field maps during credential creation
• Implement efficient serialization for common disclosure patterns

Integration Considerations

IPEX Protocol Integration: Partial disclosure operates within the IPEX (Issuance and Presentation EXchange) protocol:

• Use exn (exchange) messages to request specific field maps
• Use rpy (reply) messages to provide disclosed field maps
• Implement negotiation flows for progressive disclosure
• Support both synchronous and asynchronous disclosure patterns

TEL Registry Integration: Verify credential status before accepting partial disclosures:

• Query the TEL registry for issuance/revocation state
• Reject disclosures from revoked credentials
• Check credential expiration timestamps
• Verify the Issuer's AID key state is current

Wallet Integration: Implement partial disclosure in digital wallets:

• Provide user interfaces for selecting field maps to disclose
• Display disclosure history and audit logs
• Implement consent flows for sensitive field maps
• Support policy-based automatic disclosure decisions

Verifier Integration: Build verification systems that handle partial disclosures:

• Accept and verify compact variants
• Request additional field maps when needed
• Implement caching of disclosed field maps
• Support progressive verification workflows

Relationship to Other Disclosure Mechanisms

Comparison with Selective Disclosure

Selective disclosure provides finer-grained control than partial disclosure:

Cryptographic Foundation: Selective disclosure uses a cryptographic aggregator mechanism, while partial disclosure uses simpler SAID-based commitments.

Granularity: Selective disclosure operates on individual attributes within a flat structure, while partial disclosure operates on nested field map branches.

Correlation Properties: Selective disclosure provides stronger non-correlation guarantees - disclosed attributes cannot be correlated to undisclosed attributes in the same encompassing block. Partial disclosure does not provide this property; disclosed field maps may reveal structural information about undisclosed field maps.

Complexity: Partial disclosure is simpler to implement and understand, making it suitable for use cases where the additional privacy guarantees of selective disclosure are not required.

Comparison with Compact Disclosure

Compact disclosure is the foundational mechanism that both partial and selective disclosure build upon:

Compact Disclosure: Represents field maps by their SAIDs without revealing contents.

Partial Disclosure: Selectively expands some field maps while keeping others compact.

Full Disclosure: Expands all field maps, revealing complete credential contents.

Partial disclosure is the middle ground, enabling graduated revelation between fully compact and fully expanded forms.

Integration with Graduated Disclosure

Graduated disclosure is the overarching framework that encompasses partial disclosure:

• Progressive Revelation: Partial disclosure enables step-wise revelation of credential information
• Context-Dependent: Disclosure decisions adapt to interaction context and trust level
• Verifiable at Each Step: Each disclosure stage maintains cryptographic verifiability
• Backwards Compatible: Earlier disclosures remain valid as additional field maps are revealed

Partial disclosure is one of several graduated disclosure strategies, alongside selective disclosure, metadata disclosure, and bulk-issued credential disclosure.

Security Considerations

Privacy Implications

Structural Information Leakage: Even when field maps are not disclosed, their presence in the compact variant reveals structural information:

• The Disclosee knows that additional field maps exist
• Field map labels (keys) may reveal the nature of undisclosed information
• The number and nesting depth of field maps is visible

Mitigation: Use generic field map labels (e.g., data1, data2) or implement private ACDCs with UUIDs to blind structural information.

Correlation Risk: Disclosed field maps may enable correlation across different presentations:

• If the same field maps are disclosed to multiple Disclosees, they can correlate presentations
• Unique identifiers in disclosed field maps enable tracking
• Disclosure patterns may reveal behavioral information

Mitigation: Implement pairwise identifiers, rotate credentials frequently, and vary disclosure patterns across different Disclosees.

Attack Vectors

Substitution Attack: An attacker attempts to substitute a different field map for a SAID:

• Attack: Provide a field map that produces a different SAID than the one in the compact variant
• Detection: SAID verification fails, rejecting the substituted field map
• Prevention: Always verify SAID matches before accepting disclosed field maps

Replay Attack: An attacker replays a previously disclosed field map in a different context:

• Attack: Capture a disclosed field map and present it to a different Disclosee
• Detection: The field map is valid but may be used inappropriately
• Prevention: Implement KRAM (KERI Request Authentication Method) with timestamp-based replay protection

Selective Disclosure Attack: An attacker selectively discloses field maps to manipulate perception:

• Attack: Disclose only favorable field maps while hiding unfavorable ones
• Detection: Difficult to detect without knowledge of the complete credential structure
• Prevention: Implement disclosure policies that require specific field maps for certain transactions

Implementation Guidance

SAID Computation Algorithm

Implement recursive SAID computation for nested field maps:

import hashlib
import json

def compute_said(field_map):
    """
    Compute SAID for a field map with nested structures.
    
    Args:
        field_map: Dictionary representing the field map
        
    Returns:
        String containing the Base64-encoded SAID
    """
    # Create a copy to avoid modifying the original
    temp_map = field_map.copy()
    
    # Recursively compute SAIDs for nested field maps
    for key, value in temp_map.items():
        if isinstance(value, dict) and key != 'd':
            # Nested field map - compute its SAID first
            nested_said = compute_said(value)
            temp_map[key] = nested_said
    
    # Replace the 'd' field with placeholder
    if 'd' in temp_map:
        said_length = len(temp_map['d'])
        temp_map['d'] = '#' * said_length
    
    # Serialize to canonical JSON (insertion-ordered, no whitespace)
    canonical_json = json.dumps(temp_map, separators=(',', ':'), ensure_ascii=False)
    
    # Compute hash
    hash_bytes = hashlib.blake3(canonical_json.encode('utf-8')).digest()
    
    # Encode to Base64 URL-safe
    said = base64.urlsafe_b64encode(hash_bytes).decode('ascii').rstrip('=')
    
    return said

Compact Variant Creation

Create compact variants by replacing nested field maps with SAIDs:

def create_compact_variant(acdc, fields_to_compact):
    """
    Create a compact variant by replacing specified field maps with SAIDs.
    
    Args:
        acdc: The full ACDC structure
        fields_to_compact: List of field paths to compact (e.g., ['a.sensitiveInfo'])
        
    Returns:
        Compact variant of the ACDC
    """
    compact_acdc = acdc.copy()
    
    for field_path in fields_to_compact:
        # Navigate to the field
        path_parts = field_path.split('.')
        current = compact_acdc
        
        for i, part in enumerate(path_parts[:-1]):
            current = current[part]
        
        # Replace the field map with its SAID
        field_name = path_parts[-1]
        field_map = current[field_name]
        
        if isinstance(field_map, dict):
            said = compute_said(field_map)
            current[field_name] = said
    
    return compact_acdc

Disclosure Verification

Verify disclosed field maps match their SAID commitments:

def verify_disclosed_field_map(compact_variant, field_path, disclosed_field_map):
    """
    Verify a disclosed field map matches its SAID in the compact variant.
    
    Args:
        compact_variant: The compact ACDC variant
        field_path: Path to the field (e.g., 'a.sensitiveInfo')
        disclosed_field_map: The disclosed field map to verify
        
    Returns:
        Boolean indicating whether verification succeeded
    """
    # Navigate to the SAID in the compact variant
    path_parts = field_path.split('.')
    current = compact_variant
    
    for part in path_parts:
        current = current[part]
    
    expected_said = current  # Should be a SAID string
    
    # Compute SAID of the disclosed field map
    computed_said = compute_said(disclosed_field_map)
    
    # Verify match
    return computed_said == expected_said

Progressive Disclosure Workflow

Implement a progressive disclosure workflow:

class PartialDisclosureManager:
    def __init__(self, full_acdc):
        self.full_acdc = full_acdc
        self.disclosed_fields = set()
    
    def create_initial_presentation(self, public_fields):
        """
        Create initial presentation with only public fields disclosed.
        """
        fields_to_compact = self._get_all_fields_except(public_fields)
        compact_variant = create_compact_variant(self.full_acdc, fields_to_compact)
        self.disclosed_fields.update(public_fields)
        return compact_variant
    
    def disclose_additional_fields(self, field_paths):
        """
        Disclose additional field maps progressively.
        """
        disclosed_maps = {}
        
        for field_path in field_paths:
            if field_path not in self.disclosed_fields:
                field_map = self._get_field_map(field_path)
                disclosed_maps[field_path] = field_map
                self.disclosed_fields.add(field_path)
        
        return disclosed_maps
    
    def _get_field_map(self, field_path):
        """Navigate to and return the field map at the specified path."""
        path_parts = field_path.split('.')
        current = self.full_acdc
        
        for part in path_parts:
            current = current[part]
        
        return current
    
    def _get_all_fields_except(self, public_fields):
        """Return all field paths except the specified public fields."""
        # Implementation would traverse the ACDC structure
        # and return all field paths not in public_fields
        pass

Conclusion

Partial disclosure is a foundational privacy mechanism in the ACDC specification that enables graduated revelation of credential information through hierarchical field map structures. By operating on nested branches of the attribute tree, it provides a practical balance between privacy protection and verification requirements.

While less granular than selective disclosure, partial disclosure offers simpler implementation, clearer semantics, and sufficient privacy guarantees for many real-world use cases. Its integration with the broader KERI ecosystem - including IPEX for exchange protocols, TEL for credential status, and contractual protections for data governance - makes it a versatile tool for building privacy-preserving credential systems.

Implementers should carefully design ACDC schemas to align with expected disclosure patterns, implement robust SAID verification, and combine partial disclosure with contractual protections to create comprehensive privacy-preserving credential presentations.

Incremental Disclosure: Implement disclosure as an incremental process where previously disclosed field maps are retained and new field maps are added, rather than regenerating the entire disclosure each time.

Security Hardening

Timing Attack Mitigation: Use constant-time comparison for SAID verification to prevent timing attacks that could leak information about SAID values.

Input Validation: Validate all disclosed field maps against the ACDC schema before SAID verification to prevent malformed data from reaching cryptographic operations.

Disclosure Logging: Maintain audit logs of all disclosure operations, including which field maps were disclosed, to whom, and when. This supports accountability and incident investigation.

Integration Patterns

IPEX Message Flow: Implement partial disclosure within IPEX exchange messages using exn messages to request specific field maps and rpy messages to provide them. Support both synchronous (immediate response) and asynchronous (delayed response) patterns.

Wallet UI Design: Provide clear user interfaces that show which field maps are disclosed vs. compact, enable users to select field maps for disclosure, and display disclosure history.

Policy Enforcement: Implement disclosure policies that automatically determine which field maps to disclose based on the Disclosee's identity, the interaction context, and contractual agreements. Support both manual and automatic disclosure decisions.

Error Handling

Graceful Degradation: If a requested field map cannot be disclosed (e.g., due to policy restrictions), return the compact variant with an explanation rather than failing the entire disclosure.

Partial Failure Handling: If some field maps can be disclosed but others cannot, disclose what is possible and clearly indicate which field maps remain compact.

Version Compatibility: Handle schema version mismatches gracefully by supporting multiple schema versions and providing clear error messages when incompatibilities are detected.