Context-Dependent Semantics

Full disclosure has two distinct technical meanings depending on the disclosure context, as explicitly defined in Document 1 and Document 2:

In Selective Disclosure Context

When operating within selective disclosure mechanisms, full disclosure means detailed disclosure of the selectively disclosed attributes. Critically, this does not mean revealing all selectively disclosable attributes—only those attributes that were chosen for selective disclosure are shown in full detail.

For example, if an ACDC contains ten selectively disclosable attributes in its attribute aggregate section (A field), and the Discloser chose to selectively disclose three of them, full disclosure in this context means revealing the complete details of those three attributes, not all ten.

In Partial Disclosure Context

When operating within partial disclosure mechanisms, full disclosure means detailed disclosure of the field map that was previously only partially disclosed. This reveals the complete structure and content of specific field maps that were initially represented only by their SAID commitments.

For example, if an ACDC's attribute section (a field) was initially disclosed as just its SAID, full disclosure in this context means providing the complete attribute field map with all its nested properties.

Process Flow

Step 1: Initial Compact Disclosure

The disclosure process typically begins with compact disclosure, where field maps are represented by their SAIDs rather than full content. According to Document 8, an ACDC in compact form replaces nested field maps with their cryptographic digests:

{
  "v": "ACDC10JSON000197_",
  "d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY"
}

In this compact form, the a (attributes) field contains only the SAID of the attributes block, not the actual attribute data.

Step 2: Verification of Compact Commitment

The Disclosee receives the compact ACDC and verifies:

• The top-level SAID (d field) correctly commits to the entire structure
• The Issuer's signature on the ACDC is cryptographically valid
• The compact SAID references (like a) are properly formatted

This establishes a cryptographic commitment to the undisclosed content without revealing it.

Step 3: Negotiation and Condition Satisfaction

Before full disclosure occurs, the Discloser and Disclosee may engage in:

• Contractual agreement: Establishing legal terms for data usage (contractually protected disclosure)
• Schema disclosure: Sharing the JSON Schema to reveal data structure without content
• Progressive trust building: Multiple rounds of partial disclosure before full revelation
• Condition verification: Ensuring the Disclosee meets requirements set by the Discloser

As noted in Document 3, "additional information is revealed in subsequent steps" as "the recipient satisfies conditions set by the discloser."

Step 4: Full Disclosure Transmission

When conditions are met, the Discloser transmits the full field map content. For the example above, full disclosure of the attributes section would provide:

{
  "d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
  "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
  "dt": "2024-01-15T09:30:00.000000+00:00",
  "LEI": "254900OPPU84GM83MG36",
  "personLegalName": "Jane Smith",
  "officialRole": "Chief Financial Officer"
}

The Disclosee can now see the complete attribute details that were previously hidden behind the SAID commitment.

Step 5: Verification of Full Disclosure

The Disclosee must verify that the full disclosure is authentic by:

1. Computing the SAID of the received field map
2. Comparing the computed SAID to the SAID in the compact form
3. Confirming they match, proving the full disclosure corresponds to the original commitment

This verification process is enabled by the SAID protocol, which ensures that any modification to the field map would produce a different SAID, making tampering detectable.

Step 6: State Change and Correlation

After full disclosure, the Disclosee's knowledge state changes:

• Previously only knew the cryptographic commitment (SAID)
• Now knows the complete field map content
• Can correlate this information with other disclosed data

As noted in Document 7, "partially disclosed fields become correlatable to their encompassing block after full disclosure," which has privacy implications that must be considered in the disclosure strategy.

Technical Requirements

Cryptographic Requirements

SAID Computation Consistency: The full disclosure must produce a SAID that exactly matches the SAID in the compact representation. According to Document 27, this requires:

• Deterministic serialization: Field maps must use insertion-ordered dictionaries
• Canonical encoding: The same serialization format (JSON, CBOR, MGPK) must be used
• Recursive SAID computation: Nested field maps must be replaced by their SAIDs before computing parent SAIDs

Signature Verification: The Issuer's signature must remain valid across all disclosure variants. Document 4 emphasizes that "cross-variant Issuer commitment verifiability" is an "essential property" where "the cryptographic commitments made by the original Issuer remain verifiable throughout the disclosure process."

Integrity Chain: Full disclosure must maintain the integrity chain from:

• Issuer AID → KEL (key state verification)
• ACDC SAID → Issuer signature (authenticity)
• Field map SAID → Full content (commitment verification)

Timing Considerations

Freshness Requirements: Full disclosure may need to occur within specific time windows:

• Credential validity periods (checked via dt issuance datetime field)
• TEL status verification (ensuring credential not revoked)
• Contractual time limits for disclosure completion

Revocation Checking: Before accepting full disclosure, the Disclosee should verify the credential's status in the Transaction Event Log referenced by the ri field. A credential may be revoked between compact disclosure and full disclosure, invalidating the exchange.

Grace Periods: Some credentials include grace periods (e.g., 90 days in QVI credentials per Document 22) that affect timing of full disclosure validity.

Error Handling

SAID Mismatch: If the computed SAID of the full disclosure doesn't match the compact SAID:

• Reject the disclosure as potentially tampered or corrupted
• Log the discrepancy for security monitoring
• Do not proceed with any authorization decisions based on the data

Schema Validation Failure: If the full disclosure doesn't conform to the declared schema:

• Verify schema SAID matches the s field in the ACDC
• Validate against schema using JSON Schema validation
• Reject non-conforming data to prevent injection attacks

Signature Verification Failure: If the Issuer signature cannot be verified:

• Check KEL for key state at the time of issuance (dt field)
• Verify no key compromise occurred before issuance
• Reject if signature invalid as the ACDC cannot be trusted

Revocation Detection: If the credential is found to be revoked:

• Check TEL for revocation events
• Verify revocation timestamp relative to disclosure time
• Reject revoked credentials regardless of SAID validity

Usage Patterns

Typical Scenarios

High-Stakes Authorization: In scenarios requiring complete information for authorization decisions, such as:

• Financial transactions above certain thresholds
• Regulatory compliance verification
• Legal contract execution
• Access to sensitive systems or data

Example from Document 3: "An individual proves insurance policy coverage before engaging in extreme sports without revealing policy details. Only in the rare event of an incident (1 in 100 cases) are full policy details disclosed."

Progressive Trust Building: Full disclosure as the final step in a multi-stage trust establishment:

1. Initial compact disclosure proves credential existence
2. Partial disclosure reveals some attributes
3. Selective disclosure shows specific claims
4. Full disclosure provides complete details after trust established

Audit and Compliance: Full disclosure for audit trails and regulatory reporting:

• Complete credential details for compliance records
• Full attribute disclosure for audit verification
• Detailed field maps for forensic analysis

Credential Chaining: Full disclosure of parent credentials in ACDC chains:

• Revealing complete edge section to show credential relationships
• Disclosing full QVI credential details to verify issuer authority
• Providing complete authorization credential details for delegation verification

Best Practices

Minimize Full Disclosure: Only perform full disclosure when absolutely necessary:

• Use selective disclosure for attribute-level privacy
• Use partial disclosure for section-level privacy
• Reserve full disclosure for scenarios where complete information is required

Implement Contractual Protection: Combine full disclosure with contractually protected disclosure:

• Establish legal terms before full disclosure
• Use Ricardian contracts in the r (rules) field
• Implement chain-link confidentiality for downstream protection

Verify Before Disclosing: Disclosers should verify Disclosee authorization:

• Check Disclosee credentials before full disclosure
• Verify Disclosee meets disclosure conditions
• Confirm Disclosee has legitimate need for full information

Verify After Receiving: Disclosees must verify full disclosure authenticity:

• Always compute and verify SAIDs
• Check Issuer signatures and KEL state
• Validate against schema and business rules
• Verify credential status in TEL

Log Disclosure Events: Maintain audit trails of full disclosure:

• Record when full disclosure occurred
• Log what was disclosed to whom
• Track verification results
• Monitor for suspicious patterns

Integration Considerations

IPEX Protocol Integration: Full disclosure operates within the IPEX protocol framework:

• Use exn (exchange) messages for disclosure transactions
• Include full field maps in message payloads
• Maintain CESR encoding throughout
• Support both synchronous and asynchronous disclosure patterns

KERIA Agent Integration: When using KERIA cloud agents:

• Agents manage disclosure state transitions
• Agents verify SAIDs automatically
• Agents check TEL status
• Agents enforce disclosure policies

Wallet Integration: Client wallets must support:

• User consent for full disclosure
• Automatic SAID verification
• Disclosure history tracking
• Privacy impact warnings

Registry Integration: Full disclosure requires TEL integration:

• Query credential status before disclosure
• Verify no revocation events
• Check grace period status
• Validate registry anchoring to KEL

Privacy and Security Implications

Correlation Risk: Full disclosure increases correlation risk as noted in Document 7: "partially disclosed fields become correlatable to their encompassing block after full disclosure." This means:

• Previously unlinkable data becomes linkable
• Multiple full disclosures to different parties enable cross-correlation
• Timing of full disclosure may reveal behavioral patterns

Mitigation Strategies:

• Use contractually protected disclosure to legally restrict correlation
• Implement chain-link confidentiality for downstream protection
• Minimize full disclosure frequency and scope
• Use different credentials for different contexts when possible

Confidentiality Loss: Full disclosure represents the final lifting of confidentiality:

• Information cannot be "undisclosed" after revelation
• Disclosee gains complete knowledge of disclosed data
• Subsequent disclosures by Disclosee are outside Discloser control

Mitigation Strategies:

• Establish strong contractual terms before disclosure
• Use legal frameworks like GDPR for data protection
• Implement technical controls on Disclosee systems when possible
• Monitor for unauthorized re-disclosure

Relationship to Other Disclosure Mechanisms

Full disclosure is the final stage in a hierarchy of disclosure mechanisms:

1. Compact Disclosure: Reveals only SAIDs, no actual data
2. Partial Disclosure: Reveals some field maps, others remain compact
3. Selective Disclosure: Reveals specific attributes from aggregate
4. Full Disclosure: Reveals complete details of disclosed sections

Each stage maintains cryptographic verifiability while progressively revealing more information, enabling privacy-preserving credential presentations that can scale with trust relationships and contextual requirements.

Integration Patterns

IPEX Integration: Use exn (exchange) messages with route /presentation/full for full disclosure transactions. Embed complete field maps in the a (attributes) section of the exchange message.

KERIA Integration: Cloud agents should automatically verify SAIDs and check TEL status before accepting full disclosure. Implement disclosure state machines to track progression from compact to full.

Wallet Integration: Client wallets must obtain explicit user consent before transmitting full disclosure. Display privacy impact warnings and disclosure history.

Testing Requirements

Implementations MUST test:

• SAID computation across all supported serialization formats
• Verification with tampered field maps (should fail)
• Verification with revoked credentials (should fail)
• Verification with expired credentials (should fail)
• Cross-variant verification (compact → full)
• Progressive disclosure sequences (compact → partial → selective → full)

Security Hardening

• Implement rate limiting on full disclosure requests
• Monitor for suspicious disclosure patterns
• Use secure channels (TLS 1.3+) for transmission
• Implement replay attack protection via nonces
• Validate all inputs against schema before processing
• Use constant-time comparison for SAID verification to prevent timing attacks