user lowercase for google/apple omni-account

[BillyWooo]

tiny PR: as title

[vercel]

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

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
heima-aa-demo-app	Ignored			Nov 8, 2025 10:50pm

[claude]

Claude finished @BillyWooo's task —— View job

---

Code Review Complete ✅

Todo List

• Read and analyze the changed file parachain/primitives/src/identity.rs
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Evaluate test coverage needs
• Provide comprehensive feedback

---

Summary

This PR adds .to_lowercase() conversion for Apple, Google, and Passkey identity types in the to_omni_account method. This change ensures case-insensitive handling for these identity providers, making the behavior consistent with Email identities which already perform lowercase normalization.

📝 Code Quality & Best Practices

✅ Good:

• Follows existing patterns established for Email identity (lines 479-485)
• Consistent code style and formatting across all modified identity types
• Uses the same method chain: .unwrap_or_default().to_lowercase().as_bytes()
• Maintains backwards compatibility in the public API

⚠️ Minor Suggestion:

• Consider extracting the UTF-8 conversion + lowercase logic into a helper function to reduce code duplication across identity types

🐛 Potential Issues

⚠️ Breaking Change Warning:
This is a breaking change for existing Apple, Google, and Passkey accounts! Any existing accounts with mixed-case identifiers will generate different omni account hashes after this change.

Example Impact:

// Before this change
Identity::Apple("TestUser@example.com") → hash_A
Identity::Apple("testuser@example.com") → hash_B  

// After this change  
Identity::Apple("TestUser@example.com") → hash_B
Identity::Apple("testuser@example.com") → hash_B // Same hash now

🔒 Security Considerations

✅ Security Positive:

• Prevents account fragmentation due to case sensitivity
• Aligns with standard practice for identity normalization
• Reduces risk of user lockout due to case mismatches

⚠️ Migration Concern:

• Existing users with mixed-case Apple/Google/Passkey identities will lose access to their current omni accounts
• Consider implementing account migration logic or deprecation warnings

⚡ Performance

✅ Performance:

• Minimal overhead from .to_lowercase() operation
• No additional allocations beyond what was already happening
• Performance impact is negligible for identity operations

🧪 Test Coverage

✅ Test Status:

• Email normalization is well-tested (lines 1018-1036 show comprehensive test cases)
• The existing test demonstrates the expected behavior for case normalization

📋 Missing Test Coverage:
Tests should be added for:

• Apple identity case normalization: "TestUser" → "testuser"
• Google identity case normalization: "Test@Gmail.com" → "test@gmail.com"
• Passkey identity case normalization
• Verification that different cases produce same omni account hash

💡 Suggested Test Cases:

#[test]
fn test_apple_to_omni_account_case_normalization() {
    let identity1 = Identity::Apple(IdentityString::new("TestUser".as_bytes().to_vec()));
    let identity2 = Identity::Apple(IdentityString::new("TESTUSER".as_bytes().to_vec()));
    let identity3 = Identity::Apple(IdentityString::new("testuser".as_bytes().to_vec()));
    let client_id = "wildmeta";
    
    let hash1 = identity1.to_omni_account(client_id);
    let hash2 = identity2.to_omni_account(client_id);
    let hash3 = identity3.to_omni_account(client_id);
    
    assert_eq!(hash1, hash2);
    assert_eq!(hash2, hash3);
}

🎯 Recommendations

1. Add comprehensive tests for Apple, Google, and Passkey case normalization
2. Consider migration strategy for existing mixed-case accounts
3. Update documentation to reflect the case-insensitive behavior
4. Consider extracting helper function to reduce code duplication

✅ Overall Assessment

This is a well-implemented feature that improves user experience by providing case-insensitive identity handling. The code follows established patterns and maintains consistency across identity types. However, careful consideration should be given to the breaking change implications for existing accounts.

---