Process Flow

The bespoke credential exchange follows a carefully orchestrated multi-step sequence that ensures both parties understand and agree to terms before information is disclosed:

Step 1: Verification Request

The process begins when a verifier communicates their information requirements. This request specifies:

• What attributes or claims are needed
• The purpose for which the information will be used
• Any time constraints or validity requirements
• Context-specific parameters (e.g., location, transaction type)

This initial request establishes the scope and purpose of the disclosure, which will be encoded into the bespoke credential's rule section.

Step 2: Dataset Creation and Structure Publication

The discloser creates the dataset and publishes only the structure and field definitions, not the actual content values. This leverages compact disclosure mechanisms where:

• Field names and schema are revealed
• SAIDs (Self-Addressing Identifiers) of field values are included
• Actual data values remain hidden
• The cryptographic structure is fully verifiable

This step allows the disclosee to understand what information will be shared and in what format, without yet accessing the sensitive data itself.

Step 3: Compact ACDC Issuance

A compact ACDC is issued that reveals the credential schema but not the data values. This compact form includes:

Rule Section: Contains context-specific clauses such as:

• Anti-assimilation provisions: Limit information usage to specific purposes
• Single-use restrictions: Prevent reuse of disclosed information
• Time-bound constraints: Define validity periods
• Purpose limitations: Specify allowed uses of the data

Edge Section: References other ACDCs through edges:

• Links to supporting credentials (e.g., coupons, gift cards)
• Chains to related proofs
• Establishes the directed acyclic graph structure

Attribute Section: Includes contextual metadata:

• Date and time parameters
• Location information
• Transaction-specific details
• Usage context identifiers

The compact form uses SAIDs as placeholders for actual attribute values, maintaining cryptographic verifiability while preserving privacy.

Step 4: Signature Collection

The issuer (discloser) requests the disclosee to sign the on-the-fly contract before receiving the actual content. This signature represents:

• Explicit agreement to the usage terms in the rule section
• Acknowledgment of the anti-assimilation clauses
• Commitment to purpose-limited use of the information
• Acceptance of any time or context constraints

This step is critical because it creates a non-repudiable record of consent before sensitive information is disclosed. The signature is cryptographically bound to the compact ACDC structure, ensuring the disclosee cannot later claim ignorance of the terms.

Step 5: Content Disclosure

After the disclosee signs acceptance of the terms, they receive the actual content associated with the contract. This full disclosure transforms the compact ACDC into a complete credential by:

• Replacing SAIDs with actual attribute values
• Providing the full content of referenced edges
• Enabling verification of the complete credential chain
• Maintaining the cryptographic binding to the signed terms

The disclosee can now verify that the disclosed content matches the structure they agreed to, and the discloser has cryptographic proof that the disclosee accepted the usage terms before receiving the information.

Technical Requirements

Cryptographic Requirements

Bespoke credentials must satisfy several cryptographic properties:

1. SAID Integrity: All field values must have verifiable self-addressing identifiers
2. Signature Verification: Both discloser and disclosee signatures must be cryptographically valid
3. Chain Integrity: Edges to referenced ACDCs must maintain cryptographic links
4. Non-repudiation: Signatures must provide non-repudiable proof of agreement
5. Compact Disclosure Compliance: Structure revelation must follow ACDC compact variant specifications

Timing Considerations

The temporal sequence is critical to the security model:

• Structure Before Content: Schema must be revealed and agreed upon before data disclosure
• Signature Before Access: Disclosee signature must be collected before content release
• Time-Bound Validity: Rule sections may specify validity windows that must be enforced
• Single-Use Enforcement: Anti-assimilation clauses may require immediate invalidation after use

State Changes

The bespoke credential process involves several state transitions:

1. Initial State: Referenced ACDCs exist but are not disclosed
2. Structure Published: Compact form created with SAIDs as placeholders
3. Terms Agreed: Disclosee signature collected, creating binding contract
4. Content Disclosed: Full credential revealed, completing the exchange
5. Post-Use State: Depending on rules, credential may be invalidated or revoked

Error Handling

Implementations must handle several error conditions:

• Signature Rejection: If disclosee refuses to sign, content is never disclosed
• Verification Failure: If signatures or SAIDs don't verify, exchange is aborted
• Timeout Conditions: Time-bound credentials must handle expiration gracefully
• Revocation Scenarios: Rule violations may trigger revocation of the bespoke credential

Usage Patterns

Typical Scenarios

Bespoke credentials are particularly valuable in several common scenarios:

Restaurant Admittance Example: A concrete use case demonstrates the pattern:

• Context: Patron wants to use a gift card for restaurant admission
• Rule Section: Contains anti-assimilation clause limiting data use to single visit
• Edge Reference: Links to the gift card ACDC
• Attributes: Date, time, party size, reservation details
• Process: Restaurant signs agreement to terms, then receives proof of payment

This scenario illustrates how bespoke credentials enable single-use disclosures where the verifier must agree not to retain or reuse the information beyond the immediate transaction.

High-Stakes Credential Presentation: When presenting sensitive credentials:

• Professional licenses with usage restrictions
• Financial credentials with confidentiality requirements
• Health records with HIPAA-compliant usage terms
• Government-issued credentials with legal constraints

Consent-Based Data Sharing: For privacy-preserving exchanges:

• Selective disclosure with explicit consent
• Purpose-limited information sharing
• Time-bound access to sensitive data
• Context-specific authorization grants

Best Practices

Implementers should follow these best practices:

1. Clear Rule Sections: Make usage restrictions explicit and unambiguous
2. Minimal Disclosure: Only include attributes necessary for the specific purpose
3. Strong Anti-Assimilation: Use clear language in clauses limiting information reuse
4. Audit Trails: Maintain records of signature collection and content disclosure
5. Revocation Readiness: Implement mechanisms to revoke credentials if terms are violated

Integration Considerations

Bespoke credentials integrate with the broader ACDC ecosystem:

Tooling Reuse: The primary advantage is leveraging existing infrastructure:

• Standard issuance mechanisms
• Existing presentation exchange protocols
• Established verification processes
• Common CESR encoding and streaming

IPEX Integration: Bespoke credentials work within the Issuance and Presentation Exchange protocol:

• Follow standard message formats
• Use established OOBI discovery
• Leverage witness infrastructure for receipts
• Maintain KEL anchoring for provenance

Privacy Architecture: Bespoke credentials support privacy-preserving patterns:

• Graduated disclosure reveals information progressively
• Selective disclosure limits attribute exposure
• Chain-link confidentiality extends restrictions downstream
• Contractually protected disclosure enforces terms

Advanced Patterns

Multi-Party Bespoke Credentials

While the basic pattern involves two parties, bespoke credentials can support more complex scenarios:

• Delegated Disclosure: Where a delegate discloses on behalf of a controller
• Multi-Signature Requirements: Where multiple parties must agree to terms
• Hierarchical Disclosures: Where bespoke credentials reference other bespoke credentials

Revocation and Lifecycle Management

Bespoke credentials may have unique lifecycle requirements:

• Immediate Revocation: Single-use credentials revoked immediately after use
• Time-Based Expiration: Automatic invalidation after validity period
• Violation-Triggered Revocation: Revocation if usage terms are breached
• TEL Integration: Transaction Event Logs track credential state changes

Compliance and Legal Considerations

Bespoke credentials can encode legal requirements:

• Ricardian Contracts: Legal prose in rule sections
• Jurisdiction-Specific Terms: Compliance with local regulations
• Data Protection Requirements: GDPR, CCPA, or other privacy law compliance
• Industry Standards: Sector-specific usage restrictions

The bespoke credential pattern represents a sophisticated application of ACDC technology that transforms credential presentation into a negotiated, consent-based exchange with cryptographically enforceable terms. By leveraging existing KERI infrastructure while adding contractual layers, bespoke credentials enable privacy-preserving, purpose-bound data sharing that meets the requirements of high-stakes, regulated environments.

Error Handling

1. Signature Rejection: If disclosee refuses to sign, abort disclosure and log refusal
2. Verification Failure: If SAIDs don't match expanded content, reject and alert
3. Timeout Handling: Implement timeouts for signature collection phase
4. Revocation Checking: Verify referenced ACDCs haven't been revoked before disclosure

Security Considerations

1. Key Management: Protect discloser's signing keys used for bespoke credential issuance
2. Replay Prevention: Include nonces or timestamps to prevent replay attacks
3. Side-Channel Protection: Avoid leaking information through timing or error messages
4. Audit Logging: Maintain comprehensive logs of all bespoke credential operations

Performance Optimization

1. SAID Caching: Cache computed SAIDs to avoid recomputation
2. Signature Batching: When possible, batch signature operations
3. Streaming Support: Use CESR streaming for large credential sets
4. Lazy Expansion: Only expand compact form after signature verification

Testing Recommendations

1. Signature Verification: Test with invalid signatures to ensure rejection
2. SAID Integrity: Test with modified content to verify SAID mismatch detection
3. Rule Enforcement: Test that usage restrictions are properly enforced
4. Revocation: Test automatic revocation for single-use credentials
5. Interoperability: Test with multiple ACDC implementations