Comprehensive Explanation

CESR Proof Signatures

Protocol Definition

CESR Proof Signatures (formally specified in IETF draft draft-pfeairheller-cesr-proof) extends the Composable Event Streaming Representation protocol to provide cryptographic signature attachments on self-addressing data (SAD) structures. While CESR defines attachment codes for signatures on KERI event messages, there exists a broader class of SADs—particularly ACDC verifiable credentials—that require signature attachments but are not KERI events themselves.

The protocol addresses three critical requirements:

1. Streamability: Enabling signed SADs to be transmitted inline with other CESR content over TCP, UDP, or HTTP
2. Nested Partial Signatures: Supporting signatures on specific portions of complex nested data structures
3. Transposability: Allowing signature attachments to be moved across envelope boundaries by updating path references

The specification is authored by Phil Feairheller of GLEIF and builds upon three normative dependencies: ACDC, CESR, and SAID. The protocol is designed to work with SADs serialized in JSON, CBOR, and MessagePack formats.

Core Purpose

The abstract states: "Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity."

This capability is essential for vLEI (verifiable Legal Entity Identifier) credentials and other ACDC-based verifiable credential systems that need to embed credentials within KERI exchange (exn) messages, replay (rpy) messages, or expose (exp) events while preserving cryptographic integrity.

Version History

The specification represents an evolution of CESR's signature attachment capabilities:

• CESR Base: Defined attachment codes for KERI event message signatures
• CESR Proof Extension: Extends signature attachments to arbitrary SADs beyond KERI events
• SAD Path Language: Introduces a Base64-compatible path language for referencing nested content

Protocol Architecture

Layering Model

CESR Proof Signatures operates within a layered architecture:

Layer 1: Serialization Formats

• JSON (JavaScript Object Notation)
• CBOR (Concise Binary Object Representation per RFC8949)
• MessagePack (MGPK)

Layer 2: Self-Addressing Data (SAD)

• Data structures containing SAID fields
• Cryptographically bound identifiers derived from content
• Support for nested field maps with insertion-ordered dictionaries

Layer 3: CESR Encoding

• Dual text-binary encoding with composability
• Qualified cryptographic primitives with derivation codes
• Stream-oriented processing with self-framing

Layer 4: CESR Proof Signatures

• Signature attachments on SADs
• SAD Path Language for referencing signed content
• Transposable signature mechanisms

Component Organization

The protocol defines several key components:

SAD Path Language: A minimalist path expression syntax for specifying locations within SAD structures. Unlike JSONPointer (RFC 6901) or JSONPath, the SAD Path Language:

• Uses only the - (dash) character as path separator (Base64-compatible)
• Supports both field label and integer index path components
• Leverages static field ordering in SADs for compact syntax
• Provides deterministic path resolution rules

Signature Attachments: CESR-encoded cryptographic signatures that reference:

• The SAD being signed (via SAID)
• The path to the signed content within the SAD
• The signing AID (Autonomic Identifier)
• The signature value itself

Transposition Mechanism: Protocol rules for moving signature attachments across envelope boundaries while maintaining cryptographic integrity through path updates.

Data Flow

The typical data flow for CESR Proof Signatures:

1. SAD Construction: Create a self-addressing data structure with SAID fields
2. Path Identification: Identify the portion(s) of the SAD to be signed using SAD Path Language
3. Signature Generation: Generate cryptographic signatures over the identified content
4. Attachment Encoding: Encode signatures as CESR attachments with path references
5. Streaming: Transmit the SAD and signature attachments inline in CESR stream
6. Verification: Parse CESR stream, resolve paths, verify signatures against content

State Management

CESR Proof Signatures is fundamentally stateless at the protocol level:

• No session state required between signer and verifier
• All information needed for verification is contained in the CESR stream
• Path references are resolved deterministically from the SAD structure
• Signature verification depends only on the signed content and public key

However, implementations may maintain state for:

• Caching of KEL (Key Event Log) data for AID verification
• Resolution of OOBI (Out-Of-Band Introduction) for key discovery
• Management of witness pools for key state validation

Message Formats & Encoding

SAD Structure Requirements

For a data structure to be signable with CESR Proof Signatures, it must be a valid SAD:

Required Properties:

• Must be serializable in JSON, CBOR, or MessagePack
• Must use insertion-ordered field maps (dictionaries)
• Must contain at least one SAID field
• Must maintain static field ordering across serialization/deserialization

Version String: The v field specifies the serialization format:

• Format: ACDCvvSSSShhhhhh_
• Encodes protocol version, serialization type, size, and terminator
• Enables stream parsing without external schema

SAID Fields: Self-addressing identifiers that:

• Are cryptographic digests of the containing field map
• Use qualified CESR encoding (e.g., ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo)
• Provide content-addressable references
• Enable compact representation by replacing nested content with SAIDs

SAD Path Language Syntax

The SAD Path Language is the foundational innovation for referencing content within SADs:

Basic Syntax Rules:

1. Root Path: A single - character represents the entire SAD
2. Path Components: Delimited by - characters, can be field labels or integer indices
3. Map Context: When current context is a map, components can be:
   • Field labels (e.g., -a-personal)
   • Integer indices into map fields (e.g., -4-5)
4. Array Context: When current context is an array, components must be integer indices
5. Static Ordering: Integer indices rely on deterministic field ordering

Path Examples (using ACDC credential structure):

Absolute Paths:

• - → entire SAD (root)
• -a-personal → nested personal information map
• -4-5 → same location using field indices (4th top-level field, 5th nested field)
• -a-personal-legalName → specific field value
• -p-1 → second element in credential chain array
• -a-LEI → Legal Entity Identifier field

Integer Indexing: Enables Base64-compatible paths even when field labels contain non-Base64 characters. For example, a field labeled home-city (contains dash) can be referenced by its integer index in the field ordering.

Path Resolution Algorithm:

1. Start at root SAD
2. For each path component after initial `-`:
   a. If current context is map:
      - If component is integer: select field at that index
      - If component is label: select field with that label
   b. If current context is array:
      - Component must be integer: select element at that index
   c. Move to selected field/element as new context
3. Return final context as resolved value

Signature Attachment Format

CESR Proof Signature attachments follow CESR encoding conventions:

Attachment Structure (conceptual):

[Signature Count Code]
[Signature 1: Indexed Signature with Path]
[Signature 2: Indexed Signature with Path]
...
[Signature N: Indexed Signature with Path]

Indexed Signature Components:

1. Derivation Code: Indicates signature algorithm (e.g., Ed25519)
2. Index: Position in signing key list (for multi-sig)
3. Path Reference: SAD Path Language expression identifying signed content
4. Signature Value: Cryptographic signature bytes

CESR Encoding: All components are encoded using CESR primitives:

• Text Domain: Base64 URL-safe encoding with derivation code prefix
• Binary Domain: Compact binary representation
• Composability: Round-trip conversion between text and binary without loss

Example Signature Attachment (text domain, conceptual):

-AAB  # Count code: 2 signatures follow
0BDKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx-a-personal  # Sig 1 with path
0BELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo-a-LEI     # Sig 2 with path

Compact vs. Full Disclosure

CESR Proof Signatures supports multiple disclosure patterns:

Compact Disclosure: Replace nested field maps with their SAIDs:

{
  "v": "ACDC10JSON000197_",
  "d": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo",
  "i": "EKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx",
  "s": "EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg",
  "a": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo"
}

Full Disclosure: Include complete nested content:

{
  "v": "ACDC10JSON000197_",
  "d": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo",
  "i": "EKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx",
  "s": "EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg",
  "a": {
    "d": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo",
    "personal": {
      "legalName": "John Doe",
      "birthDate": "1990-01-01"
    },
    "LEI": "254900OPPU84GM83MG36"
  }
}

Signature Validity: A signature on the compact form is cryptographically equivalent to a signature on the full form because:

1. The SAID is a cryptographic digest of the full content
2. Verifying the signature on the SAID verifies the signature on the content
3. The path reference identifies which SAID was signed

Nested Partial Signatures

A defining feature is the ability to sign multiple portions of a SAD:

Use Case: An ACDC credential with multiple attribute sections:

{
  "v": "ACDC10JSON000197_",
  "d": "ERoot_SAID_of_entire_credential",
  "i": "EIssuer_AID",
  "a": {
    "d": "EAttributes_SAID",
    "personal": {
      "d": "EPersonal_SAID",
      "legalName": "John Doe"
    },
    "business": {
      "d": "EBusiness_SAID",
      "LEI": "254900OPPU84GM83MG36"
    }
  }
}

Signature Scenarios:

1. Sign entire credential: Path - signs root SAID
2. Sign attributes only: Path -a signs attributes SAID
3. Sign personal info: Path -a-personal signs personal SAID
4. Sign business info: Path -a-business signs business SAID
5. Sign multiple sections: Multiple signatures with different paths

Verification: Each signature is verified independently:

1. Resolve the path to identify the signed content
2. Extract the SAID at that path
3. Verify the signature against the SAID
4. Optionally verify the SAID against the full content (if disclosed)

Protocol Mechanics

Signature Generation Process

The protocol defines a deterministic process for generating CESR Proof Signatures:

Step 1: SAD Preparation

1. Construct the SAD with all required fields
2. Compute SAIDs for all nested field maps
3. Ensure insertion-ordered field maps
4. Serialize in chosen format (JSON, CBOR, or MessagePack)

Step 2: Path Identification

1. Identify the portion(s) of the SAD to be signed
2. Express each portion as a SAD Path Language expression
3. Resolve each path to verify it references a valid SAID

Step 3: Signature Computation

1. For each path: a. Resolve the path to extract the target SAID b. Serialize the SAID in CESR format c. Generate cryptographic signature using signing key d. Encode signature with path reference as CESR attachment

Step 4: Attachment Assembly

1. Collect all signature attachments
2. Prepend with CESR count code indicating number of signatures
3. Encode in chosen domain (text or binary)

Step 5: Stream Construction

1. Serialize the SAD in CESR format
2. Append signature attachments
3. Optionally include additional CESR content (e.g., KEL events)

Signature Verification Process

Verification follows a deterministic algorithm:

Step 1: Stream Parsing

1. Parse CESR stream to extract SAD and signature attachments
2. Deserialize SAD into native data structure
3. Extract signature count and individual signatures

Step 2: Path Resolution

1. For each signature: a. Extract the path reference from the signature attachment b. Resolve the path within the SAD structure c. Extract the SAID at the resolved location

Step 3: Signer Verification

1. Extract the signing AID from the signature attachment
2. Resolve the AID's current key state: a. Retrieve the KEL for the AID b. Verify KEL integrity and witness receipts c. Extract the current public key(s)
3. Verify the signature index is valid for the key state

Step 4: Signature Verification

1. For each signature: a. Extract the signature value b. Retrieve the corresponding public key c. Verify the signature against the resolved SAID d. Confirm signature is valid

Step 5: Content Verification (optional)

1. If full content is disclosed: a. Recompute SAID from disclosed content b. Verify recomputed SAID matches the signed SAID c. Confirm content integrity

Transposition Mechanism

Transposition enables signature attachments to be moved across envelope boundaries:

Scenario: An ACDC credential is embedded within a KERI exchange message:

Original Structure:

{
  "v": "KERI10JSON000197_",
  "t": "exn",
  "d": "EExchange_SAID",
  "e": {
    "acdc": {
      "v": "ACDC10JSON000197_",
      "d": "EACDC_SAID",
      "i": "EIssuer_AID",
      "a": "EAttributes_SAID"
    }
  }
}

Signature on ACDC: Path -e-acdc-a references attributes within the embedded credential.

Transposition: When the ACDC is extracted and streamed separately:

1. Path Update: Change path from -e-acdc-a to -a (relative to ACDC root)
2. Signature Preservation: The signature value remains unchanged
3. Verification: Signature verifies against the same SAID, now at a different path

Protocol Rule: Transposition is valid if:

1. The signed SAID is preserved
2. The path is updated to reflect the new structure
3. The signature value is unchanged
4. The signing AID and key state are unchanged

Message Exchange Patterns

CESR Proof Signatures supports several exchange patterns:

Pattern 1: Direct Credential Issuance

1. Issuer constructs ACDC credential
2. Issuer signs credential with CESR Proof Signature
3. Issuer streams credential and signature to issuee
4. Issuee verifies signature and stores credential

Pattern 2: Credential Presentation

1. Holder retrieves stored credential and signature
2. Holder optionally adds additional signatures (endorsements)
3. Holder streams credential and signatures to verifier
4. Verifier verifies all signatures

Pattern 3: Embedded Credential Exchange

1. Discloser embeds credential within IPEX exchange message
2. Discloser transposes signature attachments to reference embedded structure
3. Discloser streams exchange message with transposed signatures
4. Disclosee extracts credential and verifies signatures

Pattern 4: Graduated Disclosure

1. Discloser sends compact credential (SAIDs only) with signatures
2. Disclosee verifies signatures on SAIDs
3. Discloser progressively reveals full content for verified SAIDs
4. Disclosee verifies revealed content matches signed SAIDs

State Transitions

While the protocol is stateless, credential lifecycle involves state transitions:

Issuance State:

• Credential is signed by issuer
• Signature attachments reference credential structure
• Credential is recorded in TEL (Transaction Event Log)

Presentation State:

• Credential is retrieved from storage
• Signature attachments are verified
• Additional signatures may be added (endorsements)

Revocation State:

• Credential status is updated in TEL
• Signatures remain valid but credential is marked revoked
• Verifiers check TEL status during verification

Transposition State:

• Credential is embedded in different envelope
• Signature paths are updated to reflect new structure
• Signature values remain unchanged

Timing and Ordering Requirements

The protocol has minimal timing requirements:

Signature Generation: No time constraints, can be performed offline

Signature Verification: Requires access to:

• Current KEL for signing AID
• Current TEL for credential status (if applicable)
• Witness receipts for key state validation

Ordering: Signatures can be verified in any order, but:

• KEL events must be processed in order
• TEL events must be processed in order
• Signature verification depends on key state at time of signing

Expiration: Signatures do not expire, but:

• Credentials may have expiration dates
• Key state may change through rotation
• TEL status may change (revocation)

Security Properties

Threat Model

CESR Proof Signatures operates within the KERI threat model:

Assumptions:

1. Cryptographic Primitives: Hash functions and signature algorithms are secure
2. Key Management: Signing keys are protected by controller
3. KEL Integrity: Key Event Logs are verifiable and duplicity-evident
4. Witness Honesty: Sufficient witnesses are honest (threshold-based)

Adversary Capabilities:

1. Network Control: Adversary can intercept, delay, or modify network traffic
2. Witness Compromise: Adversary can compromise up to threshold of witnesses
3. Computational Power: Adversary has bounded computational resources
4. Quantum Resistance: Protocol supports post-quantum signature algorithms

Out of Scope:

1. Key Compromise: If signing keys are compromised, signatures are invalid
2. Social Engineering: Protocol does not protect against phishing or social attacks
3. Implementation Bugs: Security depends on correct implementation

Security Guarantees

Authenticity: CESR Proof Signatures provide strong authenticity guarantees:

1. Non-Repudiation: Signatures are cryptographically bound to signing AID
2. Integrity: Signatures verify content has not been modified
3. Attribution: Signatures prove authorship by controller of signing AID

Proof Mechanism:

1. Signature verifies against public key in KEL
2. KEL is verifiable back to inception event
3. Witness receipts provide distributed consensus on key state
4. Duplicity detection prevents equivocation

Confidentiality: The protocol provides limited confidentiality:

1. Compact Disclosure: SAIDs hide content from rainbow table attacks (with sufficient entropy)
2. Selective Disclosure: Only signed portions need be revealed
3. Graduated Disclosure: Content can be revealed progressively

Limitations:

1. Signatures do not encrypt content
2. SAIDs without high-entropy nonces are vulnerable to rainbow tables
3. Metadata (structure, field names) is visible even in compact form

Integrity: Strong integrity guarantees:

1. Content Binding: SAIDs cryptographically bind to content
2. Signature Binding: Signatures cryptographically bind to SAIDs
3. Path Binding: Paths identify signed content within structure

Verification:

1. Recompute SAID from disclosed content
2. Verify recomputed SAID matches signed SAID
3. Verify signature against SAID using public key
4. Verify public key is current for signing AID

Attack Resistance

Forgery Attacks: Prevented by cryptographic signatures:

1. Signature Forgery: Computationally infeasible without private key
2. SAID Forgery: Requires finding hash collision (computationally infeasible)
3. Path Manipulation: Changing path invalidates signature

Replay Attacks: Mitigated by context:

1. Credential Replay: TEL status prevents reuse of revoked credentials
2. Signature Replay: Signatures are bound to specific SAIDs
3. Timestamp Binding: Credentials can include issuance timestamps

Man-in-the-Middle Attacks: Prevented by end-to-end verification:

1. Content Modification: Invalidates SAID and signature
2. Signature Stripping: Verifier requires valid signatures
3. Key Substitution: KEL verification prevents key substitution

Duplicity Attacks: Detected by KERI mechanisms:

1. Key State Equivocation: Witness receipts detect duplicity
2. Credential Equivocation: TEL provides single source of truth
3. Signature Equivocation: Signatures are deterministic

Rainbow Table Attacks: Mitigated by entropy:

1. Public ACDCs: Vulnerable if content is predictable
2. Private ACDCs: High-entropy UUID field prevents rainbow tables
3. Selective Disclosure: Only revealed content is vulnerable

Quantum Attacks: Addressed by algorithm choice:

1. Signature Algorithms: Protocol supports post-quantum algorithms
2. Hash Functions: Protocol supports quantum-resistant hash functions
3. Key Rotation: KERI supports key rotation to post-quantum keys

Privacy Properties

Selective Disclosure: Protocol enables fine-grained disclosure:

1. Compact Form: Reveal only SAIDs, hide content
2. Partial Disclosure: Reveal some sections, hide others
3. Graduated Disclosure: Reveal content progressively

Unlinkability: Limited unlinkability properties:

1. Credential Correlation: Different credentials from same issuer are linkable via issuer AID
2. Presentation Correlation: Multiple presentations of same credential are linkable via credential SAID
3. Holder Privacy: Holder AID may be pseudonymous

Metadata Leakage: Some metadata is always visible:

1. Structure: Field names and nesting are visible
2. Schema: Schema SAID reveals credential type
3. Issuer: Issuer AID is always visible

Interoperability

Dependencies on KERI Protocols

CESR Proof Signatures has normative dependencies on:

KERI (Key Event Receipt Infrastructure):

• Provides AID (Autonomic Identifier) system
• Defines KEL (Key Event Log) structure
• Specifies witness and watcher roles
• Establishes duplicity detection mechanisms

CESR (Composable Event Streaming Representation):

• Defines encoding for cryptographic primitives
• Specifies text-binary composability
• Provides self-framing stream parsing
• Establishes derivation code system

SAID (Self-Addressing Identifier):

• Defines content-addressable identifier protocol
• Specifies digest computation rules
• Establishes self-referential data structures

ACDC (Authentic Chained Data Container):

• Primary use case for CESR Proof Signatures
• Defines credential structure and semantics
• Specifies chaining and provenance mechanisms

Integration with ACDC

CESR Proof Signatures is designed specifically for ACDC credentials:

Credential Signing:

1. ACDC defines credential structure with SAID fields
2. CESR Proof Signatures provides signature attachments
3. Signatures reference ACDC sections via SAD Path Language
4. Verification uses ACDC schema for path resolution

Chained Credentials:

1. ACDC supports credential chains via edge sections
2. Each credential in chain has independent signatures
3. Signatures verify each credential's integrity
4. Chain verification requires verifying all signatures

Selective Disclosure:

1. ACDC defines compact and full disclosure variants
2. CESR Proof Signatures supports signing both variants
3. Signatures on compact form verify full form
4. Graduated disclosure reveals content progressively

Integration with IPEX

The IPEX (Issuance and Presentation Exchange) protocol uses CESR Proof Signatures:

Issuance Exchange:

1. Issuer signs ACDC with CESR Proof Signature
2. Issuer embeds signed ACDC in IPEX exchange message
3. Issuee verifies signature and stores credential

Presentation Exchange:

1. Holder retrieves signed ACDC from storage
2. Holder embeds ACDC in IPEX presentation message
3. Verifier extracts ACDC and verifies signatures

Contractually Protected Disclosure:

1. Discloser sends compact ACDC with signatures
2. Disclosee verifies signatures on SAIDs
3. Discloser reveals full content after agreement
4. Disclosee verifies revealed content matches signed SAIDs

Integration with TEL

The TEL (Transaction Event Log) protocol tracks credential status:

Issuance Events:

1. Issuer creates ACDC and signs with CESR Proof Signature
2. Issuer anchors issuance event in TEL
3. TEL event references credential SAID
4. Verifiers check TEL for credential status

Revocation Events:

1. Issuer creates revocation event in TEL
2. Revocation event references credential SAID
3. Signatures remain valid but credential is revoked
4. Verifiers reject revoked credentials

Status Verification:

1. Verifier extracts credential SAID
2. Verifier queries TEL for status
3. Verifier checks for revocation events
4. Verifier accepts only non-revoked credentials

Integration with OOBI

The OOBI (Out-Of-Band Introduction) protocol enables discovery:

AID Discovery:

1. Verifier receives signed ACDC
2. Verifier extracts issuer AID
3. Verifier uses OOBI to discover issuer's KEL
4. Verifier verifies KEL and extracts public key

Witness Discovery:

1. Verifier extracts witness list from KEL
2. Verifier uses OOBI to discover witness endpoints
3. Verifier queries witnesses for receipts
4. Verifier verifies witness receipts

Schema Discovery:

1. Verifier extracts schema SAID from ACDC
2. Verifier uses OOBI to discover schema content
3. Verifier retrieves schema for path resolution
4. Verifier uses schema to validate credential structure

Implementation Considerations

Path Resolution Complexity

Implementing SAD Path Language requires careful handling:

Static Field Ordering: Implementations must:

1. Preserve insertion order in dictionaries/maps
2. Use ordered data structures (e.g., Python OrderedDict, JavaScript Map)
3. Serialize fields in consistent order
4. Verify field order matches across serialization formats

Integer Index Resolution: Implementations must:

1. Maintain field index mappings
2. Handle both label and index path components
3. Validate indices are within bounds
4. Support efficient index lookup

Nested Structure Traversal: Implementations must:

1. Recursively traverse nested field maps
2. Handle both map and array contexts
3. Validate path components match context type
4. Provide clear error messages for invalid paths

Signature Verification Performance

Performance considerations for verification:

KEL Caching: Implementations should:

1. Cache KEL data for frequently-used AIDs
2. Update cache when new events are received
3. Implement cache eviction policies
4. Validate cached data is current

Batch Verification: Implementations can:

1. Verify multiple signatures in parallel
2. Batch KEL retrievals for multiple AIDs
3. Optimize witness receipt verification
4. Cache public keys for repeated verification

Incremental Verification: Implementations can:

1. Verify signatures incrementally as content is disclosed
2. Skip verification of already-verified SAIDs
3. Cache verification results
4. Provide partial verification status

Transposition Implementation

Implementing transposition requires:

Path Transformation: Implementations must:

1. Parse original path from signature attachment
2. Compute new path relative to new structure
3. Validate new path resolves to same SAID
4. Update signature attachment with new path

Signature Preservation: Implementations must:

1. Preserve signature value unchanged
2. Preserve signing AID unchanged
3. Preserve signature index unchanged
4. Update only the path reference

Validation: Implementations should:

1. Verify transposed signature against original SAID
2. Verify transposed signature against new structure
3. Validate path transformation is correct
4. Provide clear error messages for invalid transposition

Error Handling

Implementations should handle common error cases:

Path Resolution Errors:

1. Invalid path syntax
2. Path component not found
3. Index out of bounds
4. Type mismatch (label in array context, index in map context)

Signature Verification Errors:

1. Invalid signature format
2. Signature verification failure
3. KEL not found for signing AID
4. Public key not found in KEL
5. Witness receipts insufficient

Content Verification Errors:

1. SAID mismatch (recomputed vs. signed)
2. Missing required fields
3. Invalid field types
4. Schema validation failure

Serialization Format Support

Implementations should support multiple formats:

JSON:

1. Use insertion-ordered dictionaries
2. Preserve field order in serialization
3. Handle Unicode characters correctly
4. Validate JSON syntax

CBOR:

1. Use CBOR maps with insertion order
2. Handle CBOR data types correctly
3. Validate CBOR encoding
4. Support CBOR tags if needed

MessagePack:

1. Use MessagePack maps with insertion order
2. Handle MessagePack data types correctly
3. Validate MessagePack encoding
4. Support MessagePack extensions if needed

Format Conversion: Implementations should:

1. Support conversion between formats
2. Preserve field order across conversions
3. Validate converted data matches original
4. Provide clear error messages for conversion failures

Testing Strategies

Implementations should include comprehensive tests:

Unit Tests:

1. Path resolution with various path expressions
2. Signature generation and verification
3. SAID computation and verification
4. Transposition with various structures

Integration Tests:

1. End-to-end credential issuance and verification
2. Graduated disclosure workflows
3. Embedded credential extraction and verification
4. TEL status checking

Interoperability Tests:

1. Cross-implementation signature verification
2. Format conversion between implementations
3. KEL and TEL compatibility
4. OOBI discovery compatibility

Performance Tests:

1. Signature verification throughput
2. Path resolution performance
3. KEL caching effectiveness
4. Batch verification scalability

Security Implementation Notes

Key Management: Implementations must:

1. Protect signing keys with appropriate security
2. Use secure random number generation
3. Implement key rotation mechanisms
4. Support hardware security modules (HSMs) if needed

Cryptographic Algorithms: Implementations should:

1. Support multiple signature algorithms (Ed25519, ECDSA, etc.)
2. Support post-quantum algorithms (Dilithium, etc.)
3. Use constant-time comparison for signature verification
4. Validate algorithm parameters

Side-Channel Resistance: Implementations should:

1. Use constant-time cryptographic operations
2. Avoid timing-dependent branches
3. Clear sensitive data from memory
4. Use secure memory allocation if available

Dependency Management: Implementations should:

1. Use well-vetted cryptographic libraries
2. Keep dependencies up to date
3. Audit dependencies for vulnerabilities
4. Pin dependency versions for reproducibility