The I2I operator is critical for implementing hierarchical trust structures such as the vLEI (verifiable Legal Entity Identifier) ecosystem, where credentials form verifiable chains from root authorities through intermediaries to end recipients.

Protocol Architecture

Credential Graph Model

ACDCs are designed as directed acyclic graph (DAG) fragments within distributed property graphs. Each ACDC serves as:

• A node representing a credential with its attributes
• A set of directed edges pointing to other ACDCs
• A graph fragment that can be cryptographically verified independently

The I2I operator defines the semantic relationship between nodes in this graph, specifically constraining how authority flows through the credential chain.

Edge Section Structure

The edges section (e) of an ACDC contains references to other credentials. Each edge includes:

• n: The SAID (Self-Addressing Identifier) of the referenced ACDC
• s: The required schema SAID that the referenced credential must conform to
• o: The operator defining the relationship logic (I2I, DI2I, or NI2I)

When the o field is omitted or explicitly set to "I2I", the I2I constraint is enforced during validation.

Layering in KERI/ACDC Stack

The I2I operator operates at the ACDC credential layer, which sits above:

• KERI identity layer: Provides AIDs (Autonomic Identifiers) with verifiable key state
• CESR encoding layer: Provides composable serialization
• KEL (Key Event Log) layer: Provides event ordering and integrity

The I2I validation logic requires access to:

• The child credential being validated
• The parent credential referenced in the edge
• The key state of both issuer and issuee AIDs

Message Formats & Encoding

ACDC Edge Section with I2I

The I2I operator is specified within the edges section of an ACDC. The edges section can be represented in two forms:

Compact Form (SAID reference only):

{
  "e": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
}

Expanded Form (full edge block):

{
  "e": {
    "d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
    "auth": {
      "n": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
      "s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
      "o": "I2I"
    }
  }
}

In this structure:

• d: The SAID of the edges block itself
• auth: A named edge (label can be any string, "auth" is conventional for authorization chains)
• n: The SAID of the parent credential
• s: The required schema SAID for the parent credential
• o: The operator, explicitly set to "I2I" (or omitted as default)

Field Semantics

Edge Label (auth in example):

• Arbitrary string chosen by credential designer
• Provides semantic meaning to the relationship
• Common labels include: auth, parent, source, delegation

SAID Reference (n field):

• Must be a valid SAID in CESR format
• Cryptographically binds to the parent credential content
• Enables content-addressable retrieval

Schema Constraint (s field):

• Enforces type safety in credential chains
• Prevents credential type confusion attacks
• Must match the schema SAID of the referenced credential

Operator (o field):

• String value: "I2I", "DI2I", or "NI2I"
• Defaults to "I2I" if omitted in KERIpy
• Determines validation logic applied to the edge

Serialization Formats

ACDCs support multiple serialization formats:

• JSON: Human-readable, used in examples
• CBOR: Binary, compact for network transmission
• MGPK: MessagePack, alternative binary format
• CESR: Native KERI streaming format

The I2I operator specification is serialization-agnostic; the same validation logic applies regardless of encoding.

Protocol Mechanics

I2I Validation Algorithm

When a validator processes an ACDC with an I2I edge, the following validation steps occur:

Step 1: Edge Resolution

• Extract the edge section from the child credential
• Identify all edges with I2I operators (explicit or implicit)
• For each I2I edge, extract the parent credential SAID (n field)

Step 2: Parent Credential Retrieval

• Resolve the parent credential using its SAID
• This may involve:
  • Local cache lookup
  • OOBI (Out-Of-Band Introduction) resolution
  • Network retrieval from credential registries
  • Watcher or witness queries

Step 3: Schema Validation

• Verify the parent credential's schema SAID matches the s field in the edge
• This ensures type safety and prevents credential substitution attacks

Step 4: I2I Constraint Verification

• Extract the issuer AID (i field) from the child credential
• Extract the issuee AID from the parent credential's attributes section
• Critical Check: Verify that child.i == parent.a.i
• If this equality does not hold, the I2I constraint is violated

Step 5: Cryptographic Verification

• Verify the digital signature on the child credential
• Verify the digital signature on the parent credential
• Verify the key state of both issuer AIDs via their KELs
• Verify any witness receipts if in indirect mode

Step 6: Registry Status Check

• If the child credential references a registry (ri field)
• Query the TEL (Transaction Event Log) for revocation status
• Verify the credential has not been revoked or nullified

State Transitions

I2I validation is stateless from the protocol perspective—each validation is independent. However, the underlying KERI infrastructure maintains state:

AID Key State:

• Each AID has a current key state derived from its KEL
• Key state includes current signing keys, thresholds, and witness configuration
• I2I validation requires current key state for both issuer and issuee AIDs

Credential Registry State:

• TELs track issuance and revocation events
• Registry state determines if a credential is currently valid
• I2I validation may require querying registry state

Timing and Ordering

I2I validation has temporal dependencies:

Parent-Before-Child Ordering:

• The parent credential MUST be issued before the child credential
• This is enforced by checking issuance timestamps (dt fields)
• Prevents circular dependencies and temporal paradoxes

Key State Synchronization:

• The issuer's key state at child credential issuance time must be verifiable
• This requires access to the issuer's KEL up to the issuance event
• Witnesses provide temporal ordering guarantees

Revocation Timing:

• If the parent credential is revoked, child credentials may become invalid
• This depends on the rules section of the child credential
• Some use cases require "orphan" credentials to remain valid after parent revocation

Security Properties

Threat Model

The I2I operator addresses several attack vectors:

Unauthorized Credential Issuance:

• Threat: An attacker issues a credential claiming authority they don't possess
• Mitigation: I2I constraint ensures issuer is the legitimate subject of the parent credential
• Example: Preventing someone from issuing "employee" credentials without being authorized by the company

Credential Chain Forgery:

• Threat: An attacker creates a fake credential chain to impersonate authority
• Mitigation: Cryptographic binding via SAIDs and I2I validation
• Example: Preventing fake "QVI authorization" credentials in the vLEI ecosystem

Type Confusion Attacks:

• Threat: Substituting a credential of one type for another in a chain
• Mitigation: Schema SAID constraint (s field) in edges
• Example: Preventing substitution of a "training certificate" for an "authorization credential"

Delegation Confusion:

• Threat: Unclear whether a credential represents direct or delegated authority
• Mitigation: Explicit I2I operator makes authority chain semantics clear
• Example: Distinguishing between "I am authorized" vs "I reference this for context"

Security Guarantees

I2I provides several cryptographic guarantees:

Verifiable Authority Chain:

• Each link in the chain is cryptographically verifiable
• Authority flows from parent to child through explicit I2I edges
• No ambiguity about the source of authority

Non-Repudiation:

• Issuers cannot deny issuing credentials due to digital signatures
• The I2I constraint creates an auditable trail of authority delegation
• All parties' AIDs are bound to their KELs

Tamper Evidence:

• Any modification to credentials breaks SAID integrity
• Any modification to the credential chain breaks I2I validation
• Duplicity detection mechanisms catch conflicting credentials

Forward Security:

• Key rotation in KERI provides forward security
• Compromised keys can be rotated without invalidating existing credentials
• Pre-rotation protects against key compromise

Attack Resistance

Rainbow Table Attacks:

• Private ACDCs include high-entropy UUIDs (u field)
• This prevents correlation attacks on credential content
• I2I validation still works with private credentials

Replay Attacks:

• Credentials include issuance timestamps (dt field)
• KERI event ordering prevents replay of old events
• Witnesses provide temporal ordering guarantees

Man-in-the-Middle Attacks:

• End-to-end verifiability prevents MITM attacks
• Credentials are signed by issuer's keys, not intermediaries
• OOBIs provide secure introduction mechanisms

Sybil Attacks:

• AIDs are cryptographically bound to KELs
• Creating fake identities doesn't grant authority without valid parent credentials
• I2I constraint prevents unauthorized credential issuance

Interoperability

Dependencies on KERI Protocols

I2I validation requires several KERI protocol components:

AID Resolution:

• AIDs must be resolvable to their current key state
• This requires access to KELs and KERLs
• OOBIs provide the discovery mechanism

Signature Verification:

• Digital signatures use KERI's cryptographic primitives
• CESR encoding provides composable signature attachments
• Indexed signatures support multisig scenarios

Event Ordering:

• KELs provide total ordering of events for each AID
• Witnesses provide distributed consensus on event ordering
• First-seen policy prevents duplicity

Registry Integration:

• TELs (Transaction Event Logs) track credential status
• Backers or registrars maintain registry state
• Registry queries are part of I2I validation flow

Integration with ACDC Features

I2I works in conjunction with other ACDC features:

Graduated Disclosure:

• I2I validation works with compact disclosure
• Parent credentials can be disclosed progressively
• Selective disclosure doesn't affect I2I constraint

Schema Composition:

• JSON Schema oneOf operators support multiple variants
• I2I validation applies regardless of compact/expanded form
• Schema constraints (s field) ensure type safety

Rules and Ricardian Contracts:

• Rules section can specify I2I-related policies
• Chain-link confidentiality can be enforced
• Legal disclaimers can reference I2I authority chains

Edge Operators:

• I2I can be combined with other operators in complex graphs
• Multiple edges can have different operators
• Nested operators (AND, OR, NOT) can include I2I constraints

Cross-Protocol Considerations

W3C Verifiable Credentials:

• ACDCs extend W3C VC data model
• I2I provides stronger authority semantics than W3C VCs
• Interoperability requires mapping I2I to VC proof chains

DID Methods:

• KERI AIDs can be expressed as did:keri or did:webs
• I2I validation works with any DID method that supports KERI
• Cross-DID-method validation requires resolver interoperability

Blockchain Integration:

• Backers can use blockchain for registry anchoring
• I2I validation is blockchain-agnostic
• Ledger-backed credentials still use I2I for authority chains

Implementation Considerations

Validation Performance

I2I validation has performance implications:

Credential Retrieval:

• Resolving parent credentials may require network operations
• Caching strategies can improve performance
• Watchers can pre-fetch credential chains

KEL Verification:

• Verifying KELs for both issuer and issuee can be expensive
• Incremental verification can optimize repeated validations
• Witnesses provide pre-verified event receipts

Registry Queries:

• TEL queries add latency to validation
• Registry caching and replication can improve performance
• Batch validation can amortize registry query costs

Error Handling

Implementations must handle various failure modes:

Missing Parent Credential:

• Parent credential SAID cannot be resolved
• May indicate network partition or unavailable issuer
• Retry logic and timeout policies required

I2I Constraint Violation:

• Issuer AID does not match parent issuee AID
• Clear error messages should indicate the specific mismatch
• Logging should capture both AIDs for debugging

Schema Mismatch:

• Parent credential schema doesn't match edge constraint
• May indicate version skew or incorrect credential reference
• Schema resolution errors should be distinguished from I2I errors

Revoked Credentials:

• Parent or child credential is revoked
• Revocation policies may differ by use case
• Some systems allow "orphaned" credentials after parent revocation

Edge Cases and Ambiguities

Delegated AIDs:

• If the issuee AID is a delegated identifier, I2I validation must account for delegation
• The DI2I operator extends I2I to handle delegation explicitly
• Implementations must decide whether to treat delegated AIDs as equivalent to root AIDs

Multisig Issuers:

• If the issuer is a multisig AID, all required signatures must be present
• Threshold requirements must be met
• Partial signatures invalidate the credential

Temporal Validity:

• Credentials may have expiration dates
• I2I validation should check temporal validity of both parent and child
• Clock skew and timezone issues must be handled

Circular References:

• I2I prevents circular credential chains by design (DAG structure)
• Implementations should detect and reject circular references
• Cycle detection algorithms may be needed for complex graphs

Testing and Validation

Implementations should include comprehensive test suites:

Positive Test Cases:

• Valid I2I chains with single and multiple hops
• Multisig issuers and issuees
• Various serialization formats (JSON, CBOR, MGPK, CESR)
• Private and public ACDCs

Negative Test Cases:

• I2I constraint violations (issuer != parent issuee)
• Schema mismatches
• Missing parent credentials
• Revoked credentials
• Invalid signatures
• Expired credentials

Edge Case Tests:

• Delegated AIDs
• Complex multisig thresholds
• Temporal edge cases (clock skew, expiration)
• Network failures during validation

Interoperability Tests:

• Cross-implementation validation
• Different serialization formats
• Various DID methods
• Blockchain-backed registries

Common Implementation Challenges

Credential Discovery:

• Finding parent credentials in distributed systems
• OOBI resolution may fail or timeout
• Caching strategies must balance freshness and performance

State Synchronization:

• Keeping KEL and TEL state current
• Witness and watcher synchronization
• Handling network partitions and eventual consistency

Scalability:

• Validating long credential chains
• Batch validation of multiple credentials
• Parallel validation of independent chains

Privacy Preservation:

• Validating I2I constraints without revealing full credential content
• Selective disclosure while maintaining I2I semantics
• Minimizing correlation risks in credential presentation

Use Cases and Applications

vLEI Ecosystem

The vLEI (verifiable Legal Entity Identifier) ecosystem extensively uses I2I:

QVI Authorization Chain:

1. GLEIF issues QVI credential to Qualified vLEI Issuer
2. QVI issues Legal Entity credential to company (I2I: QVI is issuee of GLEIF credential)
3. Legal Entity issues OOR Auth credential to QVI (I2I: LE is issuee of QVI credential)
4. QVI issues OOR credential to employee (I2I: QVI is issuee of OOR Auth credential)

Each step uses I2I to ensure proper authority flow.

ECR Credential Chain:

• Legal Entity issues ECR Auth credential to QVI
• QVI issues ECR credential to contractor (I2I constraint)
• Contractor can prove authorized engagement context role

Supply Chain Provenance

I2I enables verifiable supply chain tracking:

Manufacturer to Distributor:

• Manufacturer issues product credential
• Distributor issues shipment credential (I2I: distributor is issuee of manufacturer credential)
• Retailer issues sale credential (I2I: retailer is issuee of distributor credential)

Chain of Custody:

• Each transfer creates a new credential with I2I edge
• Provenance is cryptographically verifiable
• Tampering or unauthorized transfers are detectable

Delegated Authorization

I2I supports hierarchical authorization:

Corporate Hierarchy:

• CEO issues authorization to VP
• VP issues authorization to manager (I2I constraint)
• Manager issues authorization to employee (I2I constraint)

Project-Based Delegation:

• Project owner issues project credential
• Project lead issues task credentials (I2I constraint)
• Task assignees can prove authorized work

Educational Credentials

I2I enables verifiable academic credentials:

Accreditation Chain:

• Accrediting body issues accreditation to university
• University issues degree to student (I2I: university is issuee of accreditation)
• Student can prove degree from accredited institution

Course Completion:

• University issues instructor credential
• Instructor issues course completion credential (I2I constraint)
• Student can prove course taught by authorized instructor

Comparison with Other Operators

I2I vs DI2I

DI2I (Delegated-Issuer-To-Issuee) extends I2I to include delegated identifiers:

I2I Constraint:

• child.issuer == parent.issuee (exact match)

DI2I Constraint:

• child.issuer == parent.issuee OR
• child.issuer is delegated from parent.issuee

DI2I provides more flexibility while maintaining authority chain semantics. Use DI2I when:

• Issuers use delegated AIDs for operational security
• Key management requires separation of concerns
• Scalability demands distributed issuance

I2I vs NI2I

NI2I (Not-Issuer-To-Issuee) is permissive:

I2I Constraint:

• Strict authority chain required

NI2I Constraint:

• No required relationship between issuer and parent issuee
• Used for reference, context, or supporting evidence

Use NI2I when:

• Referencing external credentials for context
• Linking to supporting documentation
• Associating credentials without implying authority delegation

Example: A company issues a skill certification that references an external training course completion credential. The company's authority to certify skills is independent of the training provider, so NI2I is appropriate.

Operator Selection Guidelines

Use I2I when:

• Authority must flow directly through the credential chain
• Delegation is explicit and direct
• Security requires strict authority verification
• Examples: vLEI authorization chains, corporate hierarchies

Use DI2I when:

• Operational security requires delegated issuance
• Scalability demands distributed credential issuance
• Key management uses delegation for security
• Examples: Large organizations with delegated issuance infrastructure

Use NI2I when:

• Credentials reference external evidence
• No authority delegation is implied
• Context or supporting information is needed
• Examples: Skill certifications referencing training courses

Future Directions

Enhanced Operator Semantics

Future ACDC specifications may include:

• Temporal operators: Time-bounded I2I constraints
• Conditional operators: I2I with additional conditions
• Weighted operators: Fractional authority delegation

Cross-Ecosystem Interoperability

Ongoing work includes:

• Mapping I2I to W3C VC proof chains
• Integration with DIF (Decentralized Identity Foundation) standards
• Blockchain-agnostic registry protocols

Performance Optimizations

Research areas include:

• Zero-knowledge proofs for I2I validation
• Batch validation algorithms
• Incremental verification techniques
• Distributed caching strategies

Formal Verification

Future work may include:

• Formal proofs of I2I security properties
• Model checking of credential chain validation
• Automated test generation from formal specifications

Conclusion

The I2I (Issuer-To-Issuee) operator is a foundational component of the ACDC specification, providing strict authority chain semantics for verifiable credential graphs. By enforcing the constraint that a child credential's issuer must be the issuee of the parent credential, I2I enables cryptographically verifiable delegation of authority across organizational and jurisdictional boundaries.

I2I's integration with KERI's AID infrastructure, CESR encoding, and TEL registries creates a robust, scalable, and secure foundation for real-world credential ecosystems like vLEI. Understanding I2I is essential for implementing and validating ACDC-based credential systems.

• Validate multiple credentials in parallel
• Batch KEL verification operations
• Amortize registry query costs

Incremental Verification:

• Cache verified key state for AIDs
• Reuse signature verification results
• Implement checkpoint-based validation

Known Issues

NI2I Bug in KERIpy (as of documentation date):

• The NI2I operator does not work due to a bug (GitHub issue #1040)
• Workaround: Use I2I or DI2I until resolved
• Affects credential chains that require permissive edge semantics

Multisig State Synchronization (KERIA issue #316):

• In multisig groups with partial thresholds, non-signing members may not receive event notifications
• This can cause state divergence in credential validation
• Workaround: Use full participation thresholds (e.g., 3-of-3 instead of 2-of-3)

Testing Recommendations

Unit Tests:

• Test I2I constraint with matching and non-matching AIDs
• Test schema validation with correct and incorrect schemas
• Test signature verification with valid and invalid signatures

Integration Tests:

• Test full credential chain validation
• Test OOBI resolution and credential retrieval
• Test TEL registry queries

Interoperability Tests:

• Test cross-implementation validation (KERIpy, Keriox, SignifyTS)
• Test different serialization formats (JSON, CBOR, MGPK)
• Test with various DID methods (did:keri, did:webs)

Security Considerations

AID Verification:

• Always verify KEL integrity before trusting an AID
• Check for duplicity in event logs
• Verify witness receipts in indirect mode

Temporal Validation:

• Verify issuance timestamps to prevent temporal attacks
• Check credential expiration dates
• Handle clock skew gracefully

Privacy Protection:

• Use compact disclosure to minimize information leakage
• Implement selective disclosure for sensitive attributes
• Use private ACDCs with UUIDs for correlation resistance