add passkey implementation

[BillyWooo]

• Passkey Challenge System: New challenge generation and verification mechanism for secure passkey operations： executor-storage/src/passkey_challenge.rs
• Passkey Storage & Management: Storage layer for passkey credentials with CRUD operations: executor-storage/src/passkey.rs
• WebAuthn Crypto Support: Full passkey cryptographic operations including signature verification: executor-crypto/src/passkey.rs
• RPC Endpoints: New API methods for passkey lifecycle management
• • omni_requestPasskeyChallenge - Generate authentication challenges
• • omni_attachPasskey - Register new passkeys to accounts
• • omni_removePasskey - Remove passkeys from accounts

[claude]

Claude finished @BillyWooo's task —— View job

---

PR Review: Passkey Implementation

I've completed a comprehensive review of the passkey implementation. Overall, this is a well-structured implementation with good security practices. Here's my analysis:

Todo List:

• Read repository CLAUDE.md for guidelines
• Review core passkey implementation files
• Analyze RPC endpoint implementations
• Evaluate test coverage and quality
• Check for security concerns
• Assess performance considerations
• Provide comprehensive feedback

Summary

This PR implements a comprehensive passkey system with three main components:

1. Cryptographic operations (executor-crypto/src/passkey.rs) - WebAuthn attestation and signature verification
2. Storage layer (executor-storage/src/passkey.rs & passkey_challenge.rs) - CRUD operations for passkeys and challenge management
3. RPC endpoints - Three new API methods for passkey lifecycle management

Code Quality & Best Practices ✅

Strengths:

• Well-structured code with clear separation of concerns
• Comprehensive error handling with specific error types
• Good use of Rust idioms and type safety
• Proper documentation and comments
• Consistent naming conventions
• CBOR/WebAuthn standard compliance

Areas for improvement:

• Some functions are quite long (e.g., extract_credential_and_key_from_auth_data at 70+ lines)
• Consider breaking down complex parsing logic into smaller helper functions

Security Analysis 🔒

Strong security measures:

• ✅ RP ID verification: Critical check in verify_auth.rs:395 prevents phishing attacks
• ✅ Challenge-response: Proper nonce-based challenge system with expiration
• ✅ User presence/verification flags: Validates WebAuthn UP and UV flags
• ✅ Origin verification: Prevents cross-origin attacks
• ✅ Challenge consumption: One-time use prevents replay attacks
• ✅ Cryptographic verification: Proper ECDSA P-256 signature validation

Potential concerns:

1. Challenge cleanup timing: The 24-hour grace period for cleanup (passkey_challenge.rs:121) seems long. Consider reducing to 1-6 hours for better storage hygiene.

2. Error information leakage: Some error messages in RPC endpoints might reveal system internals. Consider using more generic error messages for client-facing APIs.

3. Rate limiting: No rate limiting on challenge generation - could be abused for DoS. Consider implementing per-account rate limits.

Performance Considerations ⚡

Efficient design:

• ✅ Composite key indexing (omni_account + credential_id) for O(1) lookups
• ✅ Blake2 hashing for key generation
• ✅ Lazy cleanup strategy reduces overhead

Potential optimizations:

1. Batch cleanup: The current cleanup iterates through all records. For large datasets, consider batching or indexing by expiration time.

2. Memory usage: CBOR parsing loads entire objects into memory. For very large attestation objects, consider streaming parsing.

3. Database operations: Consider connection pooling if not already implemented in StorageDB.

Test Coverage 🧪

Excellent test coverage:

• ✅ Unit tests for all core functionality
• ✅ Integration tests covering end-to-end flows
• ✅ Edge cases (expiration, duplicates, concurrency)
• ✅ Error conditions properly tested
• ✅ Challenge lifecycle thoroughly tested

Test quality is very high - comprehensive scenarios including concurrent sessions and error conditions.

Potential Bugs & Issues 🐛

1. COSE key parameter mapping (passkey.rs:337-338): The code maps COSE parameters -2 and -3 to x and y coordinates, but according to COSE spec, -2 is x-coordinate and -3 is y-coordinate. This appears correct but should be double-checked.

2. Hex decoding error handling (verify_auth.rs:381): The error message "Invalid auth data hex format" could be more specific about what went wrong.

3. Time precision (passkey_challenge.rs:276): Tests use 1-second sleep but time precision is in seconds. This could cause flaky tests on fast machines.

Recommendations 📋

High Priority:

1. Add rate limiting to challenge generation endpoints
2. Reduce cleanup grace period from 24h to 2-6h
3. Add input validation for credential_id length and format

Medium Priority:

1. Improve error messages to be less revealing of internal structure
2. Add metrics/logging for security events (failed authentications, etc.)
3. Consider adding passkey enumeration endpoint for UI purposes

Low Priority:

1. Refactor large functions for better maintainability
2. Add benchmark tests for performance validation
3. Consider adding passkey metadata (device info, last used, etc.)

Dependencies & Security 🔐

New dependencies look appropriate and are well-maintained:

• ciborium for CBOR parsing
• p256 for ECDSA cryptography

All dependencies are industry-standard choices for WebAuthn implementation.

Overall Assessment ⭐

This is a high-quality implementation that follows WebAuthn standards correctly and implements proper security measures. The code is well-tested, properly structured, and handles edge cases appropriately.

Recommendation: Approve with minor suggestions - The implementation is solid and secure, with only minor improvements suggested for production readiness.

---

[claude]

Claude finished @BillyWooo's task —— View job

---

PR Review: Passkey Implementation

This is a comprehensive and well-implemented passkey system that follows WebAuthn standards with proper security measures. Here's my detailed analysis:

Todo List:

• Read repository CLAUDE.md for guidelines
• Review core passkey implementation files
• Analyze RPC endpoint implementations
• Evaluate test coverage and quality
• Check for security concerns
• Assess performance considerations
• Provide comprehensive feedback

Summary

This PR implements a complete passkey system with three main components:

1. Cryptographic operations (executor-crypto/src/passkey.rs) - WebAuthn attestation and signature verification
2. Storage layer (executor-storage/src/passkey.rs & passkey_challenge.rs) - CRUD operations for passkeys and challenge management
3. RPC endpoints - Three new API methods for passkey lifecycle management

Code Quality & Best Practices ✅

Strengths:

• Well-structured code with clear separation of concerns
• Comprehensive error handling with specific error types
• Good use of Rust idioms and type safety
• Proper documentation and comments
• Consistent naming conventions
• CBOR/WebAuthn standard compliance

Areas for improvement:

• Some functions are quite long (e.g., extract_credential_and_key_from_auth_data at 70+ lines)
• Consider breaking down complex parsing logic into smaller helper functions

Security Analysis 🔒

Strong security measures:

• ✅ RP ID verification: Critical check in verify_auth.rs:433 prevents phishing attacks
• ✅ Challenge-response: Proper nonce-based challenge system with expiration (5 minutes)
• ✅ User presence/verification flags: Validates WebAuthn UP and UV flags in verify_auth.rs:442-453
• ✅ Origin verification: Prevents cross-origin attacks in passkey.rs:92-94
• ✅ Challenge consumption: One-time use prevents replay attacks
• ✅ Cryptographic verification: Proper ECDSA P-256 signature validation

Potential concerns:

1. Challenge cleanup timing: The 24-hour grace period for cleanup (passkey_challenge.rs:121) seems long. Consider reducing to 1-6 hours for better storage hygiene.

2. Error information leakage: Some error messages in RPC endpoints might reveal system internals. Consider using more generic error messages for client-facing APIs.

3. Rate limiting: No rate limiting on challenge generation - could be abused for DoS. Consider implementing per-account rate limits.

Performance Considerations ⚡

Efficient design:

• ✅ Composite key indexing (omni_account + credential_id) for O(1) lookups
• ✅ Blake2 hashing for key generation
• ✅ Lazy cleanup strategy reduces overhead

Potential optimizations:

1. Batch cleanup: The current cleanup iterates through all records. For large datasets, consider batching or indexing by expiration time.

2. Memory usage: CBOR parsing loads entire objects into memory. For very large attestation objects, consider streaming parsing.

3. Database operations: Consider connection pooling if not already implemented in StorageDB.

Test Coverage 🧪

Excellent test coverage:

• ✅ Unit tests for all core functionality
• ✅ Integration tests covering end-to-end flows
• ✅ Edge cases (expiration, duplicates, concurrency)
• ✅ Error conditions properly tested
• ✅ Challenge lifecycle thoroughly tested

Test quality is very high - comprehensive scenarios including concurrent sessions and error conditions.

Potential Bugs & Issues 🐛

1. COSE key parameter mapping (passkey.rs:337-338): The code maps COSE parameters -2 and -3 to x and y coordinates. According to COSE spec, -2 is x-coordinate and -3 is y-coordinate. This appears correct but should be double-checked.

2. Hex decoding error handling (verify_auth.rs:421): The error message "Invalid auth data hex format" could be more specific about what went wrong.

3. Time precision (passkey_challenge.rs:276): Tests use 1-second sleep but time precision is in seconds. This could cause flaky tests on fast machines.

Recommendations 📋

High Priority:

1. Add rate limiting to challenge generation endpoints
2. Reduce cleanup grace period from 24h to 2-6h
3. Add input validation for credential_id length and format

Medium Priority:

1. Improve error messages to be less revealing of internal structure
2. Add metrics/logging for security events (failed authentications, etc.)
3. Consider adding passkey enumeration endpoint for UI purposes

Low Priority:

1. Refactor large functions for better maintainability
2. Add benchmark tests for performance validation
3. Consider adding passkey metadata (device info, last used, etc.)

Dependencies & Security 🔐

New dependencies look appropriate and are well-maintained:

• ciborium for CBOR parsing
• p256 for ECDSA cryptography

All dependencies are industry-standard choices for WebAuthn implementation.

Overall Assessment ⭐

This is a high-quality implementation that follows WebAuthn standards correctly and implements proper security measures. The code is well-tested, properly structured, and handles edge cases appropriately.

Recommendation: Approve with minor suggestions - The implementation is solid and secure, with only minor improvements suggested for production readiness.

---

[Kailai-Wang]

Thank you - the overall logic looks fine, I didn't go very detailed into e.g. passkey verification, attach/removal.

I mainly have questions regarding db read/write

[Kailai-Wang]

Since it's "attaching" passkey, shall we check the user_id can't be of passkey type?

[BillyWooo]

Maybe not? Shall we allow multiple passkey? @Kailai-Wang

[Kailai-Wang]

Hopefully we could simpify this a bit after #3780 is merged

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
heima-aa-demo-app	Ready	Preview	Comment	Oct 30, 2025 10:04pm