Load Balancer Deduplication Requirement

The technical requirement specified in the source documents is straightforward: load balancers must have mechanisms to drop repeated requests for resources that already exist in the system.

This deduplication must occur at the infrastructure edge (the load balancer level) rather than in backend services. By implementing deduplication at this level, the system:

1. Prevents unnecessary backend processing of duplicate requests
2. Protects backend services from being overwhelmed by repeated submissions
3. Provides fast rejection of duplicates without consuming expensive computational resources
4. Maintains system availability under potential DDoS conditions

The source documents do not specify how this deduplication mechanism should be implemented - whether through in-memory caches, distributed state, or other approaches. This remains an implementation detail left to system architects.

Relationship to Registration Interaction

The source documents consistently reference registration-interaction as a related concept. The registration interaction provides important context for understanding access-controlled interactions more broadly.

A registration interaction is described as a "setup/registration interaction" involving:

• Creation of a new AID (Autonomic Identifier)
• Authorization establishment for access control
• Presentation of a vLEI credential (verifiable Legal Entity Identifier credential)

The key concern articulated is preventing credential capture and misuse during presentation. The solution suggested is narrowing the credential's scope to a specific role (exemplified as "Document Submitter") through delegatable authority. This represents a form of pre-registration that limits what actions can be performed with a presented credential.

Context-Dependent Authentication Requirements

The source documents raise several unresolved questions about authentication requirements in access-controlled interactions, particularly regarding credentials functioning as bearer tokens:

• Does it matter if the credential was delivered by the issuee?
• Does the delivery require the issuee signature?

The consistent answer across sources is: "Depends on the context."

This context dependency is influenced by several factors mentioned in the documents:

1. Process Idempotency: In idempotent processes where resubmission has no effect, signature requirements may differ from non-idempotent scenarios. If repeating an operation causes no harm, the authentication requirements might be relaxed.

2. Governance Model: The governing framework determines signature requirements. Different governance models may mandate different levels of authentication based on their risk profiles and trust assumptions.

3. Operational Context: The specific use case and threat model influence whether issuee signatures are necessary for credential delivery.

The source material explicitly notes that "depending on the context or governance model the issuance itself needs / should / could be signed," indicating variability rather than prescriptive requirements.

Bearer Token Characteristics

The documents describe credentials in access-controlled interactions as being "like a bearer token" that serves as proof of authorization. This characterization has important implications:

A bearer token, in traditional security systems, grants authority to whoever possesses it, regardless of the bearer's identity. Similarly, in some KERI access-controlled interaction contexts, possession of a valid credential may be sufficient for authorization, independent of whether the bearer is the original issuee.

However, the source documents make clear this is not a universal rule. The bearer token analogy describes one possible authentication model within access-controlled interactions, not the only model. Systems implementing access-controlled interactions must determine, based on their context and governance framework, whether:

• Credential possession alone is sufficient
• The presenter must prove they are the credential issuee
• Additional authentication factors are required

Implementation Considerations for Replay Attack Prevention

While the documents state that replay attacks are "less of a concern," they acknowledge that replay attack prevention is still critical when resubmission is used as a vector for DDoS attacks. The implementation of replay prevention depends on:

1. The operational context - different scenarios have different replay risk profiles
2. The governance model - the governing framework may specify replay prevention requirements
3. Process idempotency - idempotent operations may have different requirements than state-changing operations

The source material does not provide specific technical mechanisms for replay prevention (such as nonce validation, timestamp checking, or sequence number verification). These implementation details are left unspecified.

Scope Narrowing Through Delegatable Authority

An important pattern mentioned in the registration interaction context is using delegatable authority to narrow credential scope to specific roles. While this is discussed in relation to registration interactions specifically, it represents a broader principle applicable to access-controlled interactions generally.

By limiting a credential's authority to a specific role (like "Document Submitter"), the system:

• Reduces the impact of credential compromise or misuse
• Implements least-privilege principles
• Enables fine-grained access control
• Provides defense-in-depth through role-based authorization

This scope narrowing functions as a form of pre-registration, establishing limited authority before the actual protected operation is attempted.

Outstanding Questions and Future Development

The source material is explicitly exploratory, raising questions rather than providing definitive answers:

1. Signature Requirements: Under what circumstances should credential delivery require issuee signatures?
2. Bearer Token Security: How should systems balance the convenience of bearer tokens against the security risks?
3. Deduplication Implementation: What specific mechanisms should load balancers use for request deduplication?
4. Context Determination: How do systems determine which "context" they are operating in to make authentication decisions?

These questions reflect the early-stage nature of access-controlled interaction as a concept within KERI's development. The term captures important principles (DDoS prevention through deduplication, context-dependent authentication, credential scope narrowing) while leaving implementation details and specific requirements to be determined based on use case requirements.

Current State of Documentation

The available documentation on access-controlled interactions is minimal by design. The source documents consist of:

• Brief glossary stub entries that reference more comprehensive documentation
• Meeting notes capturing exploratory technical discussions
• References to related concepts (registration-interaction) that provide contextual understanding

This reflects an emerging concept where core principles have been identified, but detailed specifications, implementation patterns, and formal requirements remain to be developed by the KERI community.

Implementers working with access-controlled interactions should understand that they are working with a conceptual framework rather than a fully specified protocol element. The emphasis on DDoS prevention through load balancer deduplication represents the most concrete technical requirement, while authentication requirements remain context-dependent and subject to governance framework decisions.

• Track submission rates per AID
• Apply exponential backoff for repeated failures
• Use token bucket or leaky bucket algorithms
• Consider different limits for different credential types

Monitoring and Alerting: Implement comprehensive monitoring:

• Track duplicate submission rates per controller
• Alert on unusual patterns (e.g., sudden spike in duplicates)
• Monitor signature verification failure rates
• Track authorization denial patterns
• Measure deduplication index hit rates

Audit Logging: Log all access-controlled interactions:

• Controller AID
• Resource SAID
• Action attempted
• Authorization credentials presented
• Outcome (success, duplicate, unauthorized, etc.)
• Timestamp

Ensure logs are tamper-evident and retained for compliance requirements.

Context-Dependent Configuration

The source documents emphasize that security requirements "depend on the context." Provide configuration options for:

Idempotency Mode: Allow operators to configure whether operations are idempotent:

• Idempotent operations can use shorter deduplication windows
• Non-idempotent operations require longer windows
• Consider per-resource-type configuration

Governance Model: Support different governance models:

• Require issuance signatures in high-security contexts
• Allow bearer token mode for lower-risk scenarios
• Configure credential scope requirements per action type
• Support custom authorization policies

Replay Protection Level: Allow tuning of replay protection:

• Strict mode: Long deduplication windows, mandatory timestamps
• Balanced mode: Medium windows, optional timestamps
• Relaxed mode: Short windows for idempotent operations

Integration with KERI Infrastructure

KEL Access: Ensure efficient access to controller KELs:

• Maintain local KEL replicas for frequently accessed controllers
• Use watchers to detect duplicity
• Implement OOBI resolution for unknown controllers
• Cache key state with appropriate invalidation

TEL Integration: For credential verification:

• Subscribe to TEL updates for issued credentials
• Implement efficient revocation checking
• Cache credential status with short TTLs
• Handle TEL unavailability gracefully

Witness Coordination: When verifying key state:

• Query sufficient witnesses to meet TOAD threshold
• Implement timeout and retry logic
• Handle witness unavailability
• Consider using watchers as fallback

Error Handling Best Practices

Duplicate Detection: When duplicates are detected:

• Return specific error codes (not generic 400/500)
• Include the existing resource SAID in the response
• Log the duplicate attempt with controller AID
• Do NOT process the request further

Authorization Failures: When authorization fails:

• Return generic "unauthorized" errors (avoid information leakage)
• Log detailed failure reasons internally
• Implement rate limiting after repeated failures
• Consider temporary blocking for suspicious patterns

Backend Failures: When backend processing fails:

• Do NOT add to deduplication index
• Allow client retry
• Return appropriate error information
• Implement circuit breakers for backend protection

Testing Strategies

Deduplication Testing: Verify deduplication works correctly:

• Test with identical SAIDs
• Test with expired deduplication entries
• Test concurrent submissions of same resource
• Test deduplication index persistence

Security Testing: Verify security properties:

• Test with invalid signatures
• Test with revoked credentials
• Test with expired credentials
• Test with credentials outside scope
• Test replay attack scenarios
• Test DDoS scenarios with repeated submissions

Performance Testing: Verify performance under load:

• Measure deduplication check latency
• Measure signature verification throughput
• Test with high duplicate submission rates
• Test with distributed load balancer deployments

Operational Considerations

Monitoring Dashboards: Create dashboards showing:

• Request rates per controller
• Duplicate submission rates
• Authorization success/failure rates
• Deduplication index size and hit rate
• Backend processing latency

Capacity Planning: Plan capacity based on:

• Expected request rates
• Deduplication index size requirements
• Signature verification throughput
• Backend processing capacity

Incident Response: Prepare for:

• DDoS attacks through repeated submissions
• Compromised controller credentials
• Backend service failures
• Deduplication index failures

Implement runbooks for common scenarios and ensure monitoring alerts trigger appropriate responses.