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.

Witness Configuration

Proper witness configuration during AID inception is critical:

1. Select witnesses with appropriate geographic and jurisdictional diversity
2. Configure TOAD threshold to balance security (higher threshold) and availability (lower threshold)
3. Ensure witnesses are reachable and responsive during registration
4. Implement retry logic for witness communication failures
5. Consider witness rotation capabilities for long-lived AIDs

Error Handling and Rollback

Registration interactions involve multiple steps that may fail. Implement proper error handling:

1. Atomic Operations: Ensure AID creation and authorization configuration are atomic (both succeed or both fail)
2. Rollback Mechanisms: If authorization configuration fails after AID creation, rollback the AID creation
3. Partial Failure Handling: Determine how to handle scenarios like insufficient witness receipts
4. User Feedback: Provide clear error messages that guide users to resolution without exposing security details

Integration with KERIA/Signify

When integrating with KERIA (cloud agent) and Signify (web client):

1. Key Management: KERIA handles key generation and storage; Signify handles signing operations
2. Witness Communication: KERIA manages witness communication; client applications should not directly contact witnesses
3. SKRAP Protocol: Use SKRAP for secure client-to-agent communication with proper authentication
4. State Synchronization: Ensure client and agent maintain consistent view of registration state

Audit and Compliance

Implement comprehensive audit logging for compliance:

1. Log all registration attempts (successful and failed) with timestamps
2. Record credential presentations and verification results
3. Capture AID creation events and witness receipts
4. Implement tamper-evident audit logs using KERI seals
5. Provide audit trail export capabilities for compliance reporting
6. Ensure audit logs meet applicable governance framework requirements

Performance Considerations

1. TEL Query Caching: Cache credential revocation status with appropriate TTL to reduce TEL query load
2. Witness Communication: Implement parallel witness communication to reduce latency
3. Deduplication Efficiency: Use efficient data structures (hash tables) for request deduplication
4. Database Indexing: Index ACL tables by AID for efficient authorization lookups

Testing Strategies

1. Context Variation Testing: Test registration under different governance models and process types
2. Replay Attack Testing: Verify replay protection mechanisms work correctly
3. Credential Verification Testing: Test with valid, invalid, expired, and revoked credentials
4. Witness Failure Testing: Test behavior when witnesses are unavailable or unresponsive
5. Load Testing: Verify deduplication mechanisms handle high request volumes
6. Security Testing: Attempt credential capture and replay attacks to verify protections