Formal Specification Status

The NI2I operator is formally defined within the ACDC specification maintained by the Trust Over IP Foundation's Technical Stack Working Group. As documented in Document 3 and Document 4, the ACDC specification is currently at version 0.9 Draft status and defines edge operators as part of the broader ACDC edge section specification.

The operator is implemented in the reference implementation KERIpy and is intended for use through the KERI Command Line Interface (KLI) and KERIA agent systems.

Critical Implementation Status

IMPORTANT: According to Document 13, there is a blocking bug affecting NI2I operator functionality:

"The command line interface hangs indefinitely during execution when attempting to create a chained credential that utilizes the NI2I (Not-Issuer-To-Issuee) operator. Log messages are displayed but the operation never completes. No workaround is currently available. The issue is tracked in GitHub issue #1040 in the keripy repository."

Document 1 explicitly states: "the NI2I operator does not work due to a bug" and advises "For now you can skip this notebook." This represents a critical limitation for production use cases requiring NI2I functionality as of the documentation date.

Protocol Architecture

Edge Section Structure

The NI2I operator functions within the edge section (e field) of an ACDC, which is one of the top-level optional fields in the ACDC structure. According to Document 4, the edge section enables ACDCs to form labeled property graphs where:

• Each ACDC represents a node (vertex) in the graph
• The edge section defines directed edges connecting to other ACDC nodes
• Edges are identified by cryptographic references using SAIDs
• Edge operators define the logical constraints on these connections

The edge section can appear in multiple forms:

1. Compact form: The e field contains only the SAID of the edge section
2. Expanded form: The e field contains the full edge section as a nested field map

Operator Hierarchy and Composition

Edge operators in ACDC form a hierarchy of constraint levels:

1. I2I (Issuer-To-Issuee): Most restrictive - requires issuer of child to be issuee of parent
2. DI2I (Delegated-Issuer-To-Issuee): Moderate - permits delegated identifiers of the parent's issuee
3. NI2I (Not-Issuer-To-Issuee): Least restrictive - no relationship requirement

As Document 2 explains:

"NI2I is the most permissive operator. It allows any identifier to chain a child credential to a parent credential, regardless of whether the issuer has any relationship to the parent credential's issuee."

Edge operators can be combined using logical operators (AND, OR, NOT) to create complex authorization logic, though NI2I's permissive nature means it is typically used standalone for simple referential links.

Data Flow in NI2I Relationships

The data flow for NI2I-linked credentials follows this pattern:

1. Parent ACDC Creation: An issuer creates an ACDC (the "parent") with its own issuee
2. Parent ACDC Publication: The parent ACDC is published and its SAID becomes available
3. Child ACDC Creation: A different issuer creates a new ACDC (the "child") that includes an edge section
4. NI2I Edge Definition: The child's edge section references the parent's SAID with an NI2I operator
5. Verification: Verifiers can cryptographically verify both ACDCs independently and confirm the reference link

Critically, the child issuer has no authority relationship with the parent credential - they are simply creating a verifiable reference to it.

Message Formats & Encoding

Edge Section Field Structure

The edge section in an ACDC follows the standard ACDC field map structure with specific fields for defining edges. According to Document 4, the edge section is a top-level field map that can contain:

• Edge definitions: Named edges pointing to other ACDCs
• Operator specifications: The logical operator (NI2I, I2I, DI2I) governing the edge
• Edge properties: Additional metadata about the relationship

NI2I Operator Encoding

The NI2I operator is encoded as a string value within the edge definition. Based on the tutorial examples in Document 1 and Document 2, the edge section structure for NI2I follows this pattern:

{
  "e": {
    "d": "<SAID of edge section>",
    "<edge_name>": {
      "n": "<SAID of referenced parent ACDC>",
      "o": "NI2I"
    }
  }
}

Where:

• e: Top-level edge section field
• d: SAID of the edge section itself (for compact disclosure)
• <edge_name>: A semantic label for the edge (e.g., "trainingCourse", "supportingEvidence")
• n: The SAID of the parent ACDC being referenced
• o: The operator field, set to the string "NI2I"

Complete ACDC Example with NI2I Edge

Document 1 provides a conceptual example of an ACDC using NI2I to reference an external training course credential:

{
  "v": "ACDC10JSON00011c_",
  "d": "<SAID of this ACDC>",
  "i": "<Company AID>",
  "ri": "<Registry SAID>",
  "s": "<Schema SAID>",
  "a": {
    "d": "<SAID of attributes>",
    "employeeId": "EMP-12345",
    "skillName": "Advanced Data Analysis",
    "certificationDate": "2024-01-15"
  },
  "e": {
    "d": "<SAID of edge section>",
    "trainingCourse": {
      "n": "<SAID of Training Provider's Course Completion ACDC>",
      "o": "NI2I"
    }
  },
  "r": {
    "d": "<SAID of rules section>",
    "usagePolicy": "This certification is valid for internal company purposes only."
  }
}

In this structure:

• The Company issues a skill certification to an employee
• The edge section references a course completion credential from an external Training Provider
• The NI2I operator indicates this is a reference link only - the Company's authority to certify the skill does not derive from the Training Provider's credential
• The Training Provider has no relationship with the Company or the employee's employment

CESR Encoding Considerations

All ACDC fields, including edge sections, must be expressible in CESR (Composable Event Streaming Representation) format. According to Document 5, CESR provides:

• Text domain encoding: Base64 URL-safe encoding for human-readable formats
• Binary domain encoding: Compact binary representation for efficient transmission
• Composability: Ability to concatenate and parse primitives in streams

The NI2I operator string and associated SAIDs are encoded as CESR primitives, ensuring they can be transmitted in both text (JSON) and binary (CBOR, MessagePack) serializations while maintaining cryptographic verifiability.

Protocol Mechanics

NI2I Edge Creation Process

The process of creating an ACDC with an NI2I edge involves several steps, as documented in Document 1:

1. Parent ACDC Availability: The referenced parent ACDC must already exist and its SAID must be known
2. Schema Definition: The child ACDC's schema must include an edge section that permits NI2I operators
3. Edge Section Construction: The issuer constructs the edge section with:
   • A semantic edge name
   • The parent ACDC's SAID in the n field
   • The operator value "NI2I" in the o field
4. SAID Computation: The edge section's SAID is computed and included in the d field
5. ACDC Assembly: The complete ACDC is assembled with all sections
6. Top-Level SAID Computation: The ACDC's top-level SAID is computed
7. Signing: The issuer signs the ACDC using their authoritative keypair
8. Issuance: The signed ACDC is issued and anchored to the issuer's KEL

Verification Process

When a verifier receives an ACDC with an NI2I edge, the verification process includes:

1. Child ACDC Verification:

   • Verify the child ACDC's SAID matches its content
   • Verify the issuer's signature
   • Verify the issuer's key state via their KEL
   • Validate against the declared schema

2. Edge Section Verification:

   • Verify the edge section's SAID matches its content
   • Confirm the operator is "NI2I"
   • Extract the parent ACDC's SAID from the n field

3. Parent ACDC Retrieval and Verification:

   • Retrieve the parent ACDC using its SAID
   • Verify the parent ACDC's SAID matches its content
   • Verify the parent's issuer signature
   • Verify the parent's issuer key state

4. NI2I Constraint Validation:

   • No relationship validation required - this is the key distinction of NI2I
   • The verifier confirms the reference exists and is cryptographically valid
   • No check is performed to ensure the child's issuer has any relationship to the parent's issuee

As Document 2 emphasizes:

"With NI2I, there is no requirement for the issuer of the child credential to have any relationship with the issuee of the parent credential. This makes NI2I suitable for scenarios where one party wants to reference or link to another credential for informational or contextual purposes, without claiming any authority derived from that credential."

State Management

NI2I edges are stateless references - they do not create or modify state in either the parent or child ACDC. The relationship is purely referential:

• The parent ACDC is unaware of child ACDCs that reference it
• The child ACDC maintains a cryptographic pointer to the parent
• No bidirectional relationship is established
• Revocation of the parent does not automatically affect the child (though verifiers may apply business logic based on parent status)

Timing and Ordering Requirements

The only temporal requirement for NI2I edges is that the parent ACDC must exist before the child ACDC is created, since the child needs the parent's SAID to construct the edge reference. However:

• The parent need not be "active" or "valid" at child creation time
• The parent's revocation status is independent of the child's validity
• Verifiers may apply business logic about parent status, but the protocol itself imposes no constraints

Security Properties

Threat Model

The NI2I operator's permissive nature creates specific security considerations:

Unauthorized Reference Attacks

Since NI2I permits any issuer to reference any ACDC, malicious actors could:

• Create misleading associations: Issue credentials that reference prestigious credentials to imply false endorsements
• Reputation hijacking: Link to high-reputation credentials to transfer trust inappropriately
• Context manipulation: Reference credentials out of context to misrepresent their meaning

Mitigation: These attacks are mitigated through:

1. Cryptographic independence: Each ACDC's validity is independently verifiable - the parent's signature does not extend to the child
2. Explicit operator semantics: The NI2I operator explicitly signals "no authority transfer"
3. Verifier business logic: Verifiers must implement appropriate business rules about what NI2I references mean in their context
4. Governance frameworks: Ecosystems like vLEI define acceptable use of edge operators

Reference Integrity

NI2I edges rely on SAID-based references, which provide:

• Immutability: The SAID cryptographically binds to specific content - any modification changes the SAID
• Verifiability: Verifiers can confirm the referenced ACDC matches the SAID
• Tamper evidence: Any attempt to substitute a different ACDC will fail SAID verification

Security Guarantees

NI2I provides these security guarantees:

1. Cryptographic Binding: The edge reference is cryptographically bound to a specific parent ACDC via its SAID
2. Non-Repudiation: The child ACDC's issuer cannot deny creating the reference (their signature commits to the edge section)
3. Independent Verification: Both parent and child ACDCs can be verified independently
4. No Implicit Authority: The protocol explicitly does not grant authority from parent to child

Attack Resistance

NI2I edges resist several attack vectors:

SAID Collision Attacks

An attacker attempting to create a malicious ACDC with the same SAID as a legitimate parent would need to:

• Find a collision in the cryptographic hash function (e.g., Blake3-256)
• This is computationally infeasible with current cryptographic standards
• KERI's use of post-quantum resistant algorithms further strengthens this

Replay Attacks

NI2I edges are not vulnerable to replay attacks because:

• Each ACDC is uniquely identified by its SAID
• The edge reference is part of the signed ACDC content
• Timestamps and registry anchoring provide temporal context

Man-in-the-Middle Attacks

NI2I references are resistant to MITM attacks because:

• The SAID provides content integrity - any modification is detectable
• The issuer's signature provides authenticity
• KERI's witness infrastructure provides availability and consistency

Privacy Considerations

NI2I edges have specific privacy implications:

Correlation Risk

NI2I edges create explicit correlation points between credentials:

• The child ACDC publicly references the parent's SAID
• This creates a verifiable link that can be used for correlation
• Unlike selective disclosure, the edge reference is typically not blinded

Mitigation strategies:

1. Private ACDCs: Use UUID fields to blind the parent ACDC's SAID
2. Compact disclosure: Present only the edge section's SAID initially, revealing the full edge later
3. Graduated disclosure: Progressively reveal the edge relationship as trust is established

Information Leakage

The mere existence of an NI2I edge reveals:

• That the child issuer is aware of the parent ACDC
• That the child issuer considers the parent relevant
• The semantic relationship implied by the edge name

This information leakage must be considered in privacy-sensitive applications.

Interoperability

Dependencies on KERI/ACDC Protocols

NI2I is deeply integrated with the broader KERI/ACDC protocol stack:

KERI Dependencies

1. AID Infrastructure: Both parent and child ACDC issuers must have valid AIDs with verifiable KELs
2. Key State Verification: Verifiers must be able to query and verify the key state of both issuers
3. Witness Network: The witness infrastructure provides consistency and availability for KELs
4. OOBI Protocol: Out-of-Band Introductions enable discovery of AIDs and their endpoints

ACDC Dependencies

1. SAID Protocol: NI2I edges rely on SAIDs for content-addressable references
2. Schema System: Edge sections must conform to ACDC schema definitions
3. Serialization: Edge sections must be serializable in ACDC-supported formats (JSON, CBOR, MGPK)
4. Registry System: ACDCs with NI2I edges may be anchored to TEL registries

Integration with Other Edge Operators

NI2I can be combined with other edge operators using logical composition:

AND Composition

Multiple edges with different operators can coexist:

{
  "e": {
    "d": "<edge section SAID>",
    "parentCredential": {
      "n": "<parent SAID>",
      "o": "I2I"
    },
    "supportingEvidence": {
      "n": "<evidence SAID>",
      "o": "NI2I"
    }
  }
}

This structure requires:

• The issuer must be the issuee of parentCredential (I2I constraint)
• The issuer can reference supportingEvidence without relationship constraints (NI2I)

OR Composition

Edge operators can be composed with OR logic for flexible authorization:

{
  "o": {
    "OR": [
      {"o": "I2I"},
      {"o": "NI2I"}
    ]
  }
}

This allows either direct authority (I2I) or referential linking (NI2I).

Ecosystem Integration

NI2I is used in several KERI ecosystem contexts:

vLEI Ecosystem

The vLEI ecosystem, managed by GLEIF, uses edge operators including NI2I for:

• Linking organizational credentials to external certifications
• Referencing regulatory compliance documents
• Associating role credentials with supporting qualifications

As Document 9 notes, the vLEI implementation demonstrates sophisticated use of ACDC edge operators in a production ecosystem.

Signify/KERIA Integration

The Signify client libraries and KERIA agent system provide infrastructure for NI2I operations:

• Edge signing: Signify clients sign ACDCs with edge sections at the edge
• Agent management: KERIA agents manage ACDC storage and presentation
• Registry operations: KERIA handles TEL anchoring for ACDCs with edges

However, as noted in Document 13, the current implementation has blocking bugs affecting NI2I functionality.

Implementation Considerations

Schema Design for NI2I Edges

When designing ACDC schemas that support NI2I edges, implementers should:

1. Define semantic edge names: Choose meaningful labels that clearly indicate the relationship type
2. Specify operator constraints: Explicitly document which operators are permitted for each edge
3. Include edge section schemas: Define the structure of the edge section in the ACDC schema
4. Consider privacy implications: Decide whether edges should be blinded or public

Document 7 provides detailed examples of schema design with edge sections, showing how oneOf composition operators enable multiple variants.

Verification Logic Implementation

Implementers of ACDC verifiers must:

1. Parse edge sections: Extract edge definitions and operator specifications
2. Retrieve referenced ACDCs: Use SAIDs to fetch parent ACDCs
3. Verify cryptographic properties: Validate SAIDs, signatures, and key states
4. Apply operator semantics: For NI2I, confirm the reference exists but do not enforce relationship constraints
5. Implement business logic: Apply ecosystem-specific rules about NI2I usage

Performance Considerations

NI2I edges have performance implications:

Verification Overhead

Each NI2I edge requires:

• Retrieval of the parent ACDC (network operation)
• Cryptographic verification of the parent (CPU-intensive)
• Key state verification for the parent's issuer (network + CPU)

For ACDCs with multiple NI2I edges, this can create significant verification latency.

Optimization strategies:

1. Caching: Cache verified parent ACDCs to avoid repeated retrieval
2. Parallel verification: Verify multiple edges concurrently
3. Lazy verification: Verify edges only when needed for specific business logic
4. Compact disclosure: Present only edge SAIDs initially, expanding on demand

Storage Considerations

NI2I edges increase ACDC size:

• Each edge adds the parent's SAID (typically 44 bytes in Base64)
• Edge section metadata adds additional overhead
• Multiple edges compound this effect

For resource-constrained environments, consider:

• Using compact disclosure to minimize transmitted data
• Storing only edge SAIDs locally, fetching full edges on demand
• Implementing edge pruning for expired or irrelevant references

Error Handling

Implementers must handle several error conditions:

1. Missing parent ACDC: The referenced SAID cannot be resolved
2. Invalid parent ACDC: The parent fails cryptographic verification
3. Revoked parent: The parent's registry shows revocation status
4. Operator mismatch: The edge operator doesn't match schema requirements
5. Circular references: Edge chains that loop back to earlier ACDCs

Testing Strategies

Given the current bug status (Document 13), implementers should:

1. Monitor bug resolution: Track GitHub issue #1040 in the keripy repository
2. Test with I2I first: Validate basic edge functionality with working operators
3. Prepare test scenarios: Develop NI2I test cases for when the bug is resolved
4. Implement fallbacks: Design systems that can function without NI2I until it's available

Governance Framework Integration

NI2I usage should be governed by ecosystem-specific rules:

1. Define acceptable use cases: Specify when NI2I references are appropriate
2. Establish verification policies: Define how verifiers should interpret NI2I edges
3. Document semantic conventions: Standardize edge names and their meanings
4. Implement audit mechanisms: Track NI2I usage for compliance monitoring

The vLEI Ecosystem Governance Framework provides a model for such governance structures.

Comparison with Other Edge Operators

NI2I vs. I2I

The key differences between NI2I and I2I:

As Document 2 explains:

"I2I enforces a strict constraint: the issuer of a child credential MUST be the issuee (subject) of the parent credential. This creates a direct chain of authority... NI2I, in contrast, allows any identifier to chain a child credential to a parent credential, regardless of whether the issuer has any relationship to the parent credential's issuee."

NI2I vs. DI2I

The key differences between NI2I and DI2I:

Document 2 notes:

"DI2I extends the strict I2I constraint to include formally recognized delegates, enabling security, flexibility, and scalability through the single responsibility pattern and reduced exposure of parent AID signing keys."

NI2I, by contrast, imposes no delegation requirements whatsoever.

Use Cases and Applications

Referencing External Certifications

The primary use case demonstrated in Document 1 involves a company issuing skill certifications that reference external training courses:

Scenario:

• A Training Provider issues a "Course Completion" credential to an employee
• The employee's company issues an "Employee Skill Certified" credential
• The skill certification uses NI2I to reference the course completion
• The company's authority to certify the skill is independent of the training provider

This demonstrates NI2I's value for:

• Acknowledging supporting evidence without claiming authority from it
• Creating verifiable links to third-party credentials
• Maintaining organizational independence while providing context

Supporting Documentation Links

NI2I enables credentials to reference supporting documentation:

• Regulatory compliance credentials referencing audit reports
• Professional certifications referencing continuing education records
• Product certifications referencing test results from independent labs

In each case, the issuer maintains independent authority while providing verifiable references to supporting evidence.

Contextual Information

NI2I can link credentials to contextual information:

• Employment credentials referencing organizational structure credentials
• Project credentials referencing organizational capability credentials
• Individual credentials referencing organizational membership credentials

These links provide context without implying that the referenced credentials grant authority for the linking credential.

Cross-Ecosystem References

NI2I enables credentials from one ecosystem to reference credentials from another:

• Healthcare credentials referencing educational credentials
• Financial credentials referencing identity credentials
• Supply chain credentials referencing certification credentials

This cross-ecosystem linking is particularly valuable in scenarios where different governance frameworks operate independently but need to reference each other's credentials.

Future Directions

The NI2I operator's development and adoption will likely evolve in several directions:

Bug Resolution

The immediate priority is resolving the blocking bug documented in Document 13. Once GitHub issue #1040 is resolved, NI2I will become practically usable in production systems.

Semantic Standardization

As NI2I usage grows, ecosystems will likely develop:

• Standard edge names for common reference types
• Conventions for when NI2I is appropriate vs. other operators
• Best practices for privacy-preserving NI2I usage

Enhanced Privacy Features

Future developments may include:

• Blinded NI2I edges using zero-knowledge proofs
• Selective disclosure of edge sections
• Privacy-preserving edge verification protocols

Tooling and Developer Experience

As the KERI ecosystem matures, expect:

• Improved CLI commands for NI2I edge creation
• Better error messages and debugging tools
• Graphical tools for visualizing ACDC graphs with NI2I edges
• Enhanced documentation and tutorials

Governance Framework Evolution

Governance frameworks like the vLEI EGF will likely:

• Define more specific policies for NI2I usage
• Establish audit requirements for NI2I references
• Create liability frameworks for inappropriate NI2I usage
• Develop dispute resolution mechanisms for NI2I-related issues

Error Handling

Implement robust error handling for:

1. Missing Parent: Handle cases where the referenced SAID cannot be resolved
2. Invalid Parent: Detect when parent ACDC fails cryptographic verification
3. Revoked Parent: Check parent's registry status and apply appropriate business logic
4. Circular References: Detect and prevent infinite loops in edge chains
5. Operator Mismatch: Validate that edge operators match schema requirements

Security Considerations

1. No Implicit Trust: Never assume NI2I edges grant authority - they are references only
2. Independent Verification: Always verify both parent and child ACDCs independently
3. Business Logic Required: Implement ecosystem-specific rules for interpreting NI2I references
4. Correlation Awareness: Recognize that NI2I edges create explicit correlation points
5. Privacy Protection: Consider using compact disclosure or blinding for sensitive edges

Governance Framework Integration

When deploying NI2I in production ecosystems:

1. Define Acceptable Use: Document when NI2I references are appropriate
2. Establish Verification Policies: Specify how verifiers should interpret NI2I edges
3. Standardize Semantics: Create conventions for edge names and their meanings
4. Implement Auditing: Track NI2I usage for compliance monitoring
5. Provide Recourse: Establish mechanisms for addressing inappropriate NI2I usage

Testing Strategy

Given the current bug status:

1. Unit Tests: Create test cases for NI2I edge parsing and validation logic
2. Integration Tests: Prepare end-to-end tests for when bug is resolved
3. Fallback Testing: Verify system behavior when NI2I is unavailable
4. Edge Case Testing: Test circular references, missing parents, invalid operators
5. Performance Testing: Measure verification overhead with multiple NI2I edges