Comprehensive Explanation

registration-interaction

Source Context and Nature

Registration-interaction appears in KERI documentation as informal technical commentary rather than a formally specified process. The term emerged from technical discussions among KERI Suite core contributors (Samuel Smith, Daniel Hardman, and Lance Byrd) during a KERI Suite Zoom meeting on January 16, 2024 (discussion minutes 30-60). The available documentation explicitly characterizes these as exploratory notes with unresolved questions rather than settled specifications.

Basic Concept

The sources describe registration-interaction as a setup/registration interaction where:

1. A new AID (Autonomic Identifier) is created
2. Authorization is established to set up access control
3. A credential is presented (specifically a vLEI credential) as part of the process

The core concern articulated across sources is preventing credential capture and misuse during this presentation. The documentation suggests that narrowing scope to specific roles (exemplified as "Document Submitter") represents a form of pre-registration using delegatable authority.

Open Questions and Context Dependencies

Credential Delivery Requirements

The sources repeatedly emphasize that key implementation details depend on context rather than being universally specified. The most prominent unresolved question is:

Does the credential need to be delivered by the issuee?

The sources frame credentials as functioning "like a bearer token" where possession provides proof of authorization. However, multiple documents explicitly state: "Does the delivery require the issuee signature? Depends on the context."

This context-dependency means:

• In some governance models, issuee signatures may be required for credential presentation
• In other contexts, the credential itself may be sufficient for authorization
• The specific requirements are determined by the applicable governance framework

Governance Model Influence

One source explicitly states: "depending on the context or governance model the issuance itself needs / should / could be signed." This indicates that:

• Governance frameworks define signature requirements
• Different operational contexts warrant different authentication levels
• There is no universal specification for registration-interaction security requirements

Security Considerations

Scope Narrowing Through Delegation

Multiple sources emphasize narrowing the scope to specific roles through delegatable authority as a critical security feature. Rather than presenting a broad credential that could be captured and misused, the approach involves:

1. Pre-registration scope limitation: Creating credentials limited to specific roles (e.g., "Document Submitter")
2. Delegatable authority: Using KERI's delegation mechanisms to restrict what actions can be performed
3. Minimizing exposure: Presenting only the authority necessary for the specific interaction

This represents a form of contingent disclosure where only minimum necessary authority is revealed.

Replay Attack Prevention

The sources emphasize that replay attack prevention is important for registration interactions, but with significant qualifications:

• Requirements vary "depending on the context or governance model"
• The specific mechanisms are not detailed in available sources
• Implementation depends on whether the process is idempotent

One source references KRAM (KERI Request Authentication Method) in the broader glossary context, which includes ISO-8601 timestamp validation within acceptable time windows, but does not explicitly specify KRAM as a requirement for registration-interactions.

Idempotency Considerations

Multiple sources note that idempotent processes (where resubmission has no effect) may have different signature requirements than non-idempotent operations. This design consideration affects implementation:

• For idempotent processes: The risk profile differs since resubmission cannot cause harm
• For non-idempotent operations: Stronger replay attack prevention may be necessary
• The specific requirements depend on the operational context

Relationship to Access-Controlled Interactions

Several sources reference access-controlled-interaction as a related concept. The access-controlled interaction documentation addresses:

• Actions requiring authorization (such as report submission)
• Request deduplication: Load balancers need mechanisms to drop repeated requests
• DDoS attack concerns: Repeated submissions could be weaponized for denial-of-service
• Limited replay attack concerns: Replay attacks are "less of a concern" in this context, except as DDoS vectors

This suggests that registration-interaction and access-controlled-interaction are part of a broader framework for managing different types of interactions in KERI systems, though the sources do not provide detailed specifications for this framework.

Technical Implementation Gaps

The available documentation reveals several areas where technical details are not specified:

Unspecified Process Steps

While sources mention "new AID creation" and "authorization establishment," they do not detail:

• The specific sequence of operations
• Error handling procedures
• Witness configuration requirements for the new AID
• Key rotation considerations
• Confirmation mechanisms after successful registration

Unspecified Cryptographic Requirements

Sources do not specify:

• Whether pre-rotation is required for the new AID
• Signature verification procedures for presented credentials
• SAID verification requirements for ACDC credentials
• TEL (Transaction Event Log) revocation checking procedures

Unspecified Integration Patterns

Sources do not detail:

• How registration-interaction integrates with IPEX (Issuance and Presentation Exchange)
• Witness receipt requirements and timing
• Registry interaction patterns
• Service endpoint discovery mechanisms

Documented Security Questions

The sources explicitly identify several security questions that remain context-dependent:

1. Bearer Token Characteristics: When a credential functions as proof-of-authority, is possession sufficient?
2. Issuee Authentication: Must the presenter prove they are the legitimate issuee through signatures?
3. Signature Requirements: Do different governance models require different signature levels?
4. Replay Prevention: What specific mechanisms are appropriate for different operational contexts?
5. Idempotency Effects: How do idempotent vs. non-idempotent processes affect security requirements?

Conclusion

The available documentation on registration-interaction consists primarily of informal technical commentary with unresolved questions rather than formal specifications. The core concept involves creating a new AID and establishing authorization through credential presentation, with emphasis on scope narrowing to prevent credential misuse.

However, critical implementation details—including signature requirements, credential verification procedures, and replay attack prevention mechanisms—are explicitly characterized as context-dependent and determined by applicable governance frameworks rather than universal protocol specifications.

Developers implementing registration interactions must:

1. Consult applicable governance frameworks to determine specific requirements
2. Consider operational context when designing security mechanisms
3. Implement scope narrowing through delegatable authority
4. Account for idempotency in security design
5. Recognize that universal specifications do not currently exist in documented sources

The informal nature of available documentation suggests this terminology may represent work-in-progress discussions rather than settled protocol specifications, reflecting ongoing design conversations within the KERI community.