+
⭐ SUPPORT Pheromind ⭐
+
Help fund continued development and new features!
+
+
+
+
+
+
❤️ Your support makes a huge difference! ❤️
+
Pheromind is maintained by a single developer
Every donation directly helps improve the tool
+
+
+
+Unleash the collective, verifiable intelligence of Pheromind and transform how your complex projects are executed.
diff --git a/reports/debug_WalletFrameworkCore.md b/reports/debug_WalletFrameworkCore.md
new file mode 100644
index 00000000..9ed9e2fd
--- /dev/null
+++ b/reports/debug_WalletFrameworkCore.md
@@ -0,0 +1,34 @@
+# Diagnosis Report: WalletFrameworkCore Test Execution Failure
+
+**Feature Name:** WalletFrameworkCore
+
+**Issue:** Test execution failed with an MSBuild error indicating the project file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` did not exist.
+
+**Previous Attempt Details:**
+- Command: `dotnet test test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj`
+- Error: `MSBuild error: project file did not exist`
+- Modified Code Paths: [`src/WalletFramework.Core/Base64Url/Base64UrlEncoder.cs`](src/WalletFramework.Core/Base64Url/Base64UrlEncoder.cs), [`src/WalletFramework.Core/Base64Url/Base64UrlDecoder.cs`](src/WalletFramework.Core/Base64Url/Base64UrlDecoder.cs)
+
+**Diagnosis Steps:**
+1. Verified the existence and location of the test project file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` using the `list_files` tool. The file was confirmed to exist at the specified path.
+2. Attempted to re-run the `dotnet test` command with increased verbosity (`-v d`) to gather more details about the MSBuild error. The command failed with the same "project file does not exist" error (MSBUILD : error MSB1009).
+
+**Findings:**
+Despite repeated verification that the test project file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` exists at the specified path within the project directory, the `dotnet test` command consistently reports that the file does not exist. This indicates that the issue is likely not a simple case of a missing or incorrectly specified file path.
+
+**Possible Root Causes:**
+- **Permissions Issues:** The user account executing the `dotnet test` command may lack the necessary file system permissions to access or read the `.csproj` file.
+- **Environment Configuration:** There might be an issue with the .NET environment setup, including environment variables or NuGet configuration, that is preventing MSBuild from correctly resolving the project path.
+- **Transient File System Issue:** Although less likely given repeated failures, a temporary file system lock or corruption could potentially cause this.
+- **Antivirus or Security Software Interference:** Security software could be blocking access to the project file during the build process.
+- **.NET SDK Installation Issue:** A problem with the .NET SDK installation itself could lead to MSBuild errors.
+
+**Conclusion:**
+The test execution failure is caused by MSBuild being unable to locate or access the test project file, despite its confirmed presence on the file system. The exact root cause requires further investigation into the execution environment, including user permissions, .NET configuration, and potential interference from other software.
+
+**Recommendations for Further Investigation:**
+- Verify file system permissions for the user running the command on the `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` file.
+- Attempt to run the `dotnet test` command from a different terminal or with elevated privileges (if applicable and safe to do so).
+- Check .NET environment variables and NuGet configuration.
+- Temporarily disable antivirus or security software (with caution) to rule out interference.
+- Consider repairing or reinstalling the .NET SDK.
\ No newline at end of file
diff --git a/reports/debug_WalletFrameworkCore_attempt2.md b/reports/debug_WalletFrameworkCore_attempt2.md
new file mode 100644
index 00000000..b95688ef
--- /dev/null
+++ b/reports/debug_WalletFrameworkCore_attempt2.md
@@ -0,0 +1,31 @@
+# Diagnosis Report: WalletFrameworkCore Test Execution Failure (Attempt 2)
+
+**Feature Name:** WalletFrameworkCore
+
+**Issue:** Test execution failed with an MSBuild error indicating the project file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` did not exist, despite the file being present on the file system.
+
+**Analysis:**
+Based on the previous diagnosis report (`reports/debug_WalletFrameworkCore.md`), the test project file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj` has been verified to exist at the specified location. However, the `dotnet test` command consistently fails with an MSBuild error (MSBUILD : error MSB1009) stating that the project file does not exist. This indicates that the issue is not a simple file path error but is related to how MSBuild or the .NET environment is interacting with the file system or project structure during the build process.
+
+The code comprehension report (`analysis_reports/BUG-789/code_comprehension_report_WalletFrameworkCore.md`) identified potential code-level issues within the `Base64UrlEncoder` and `Base64UrlDecoder` classes, specifically regarding missing `DecodeBytes` and incorrect calls to the `Decode` method. While these findings are relevant to potential test failures *if* the tests were able to run, they are not the cause of the current MSBuild error which occurs *before* the code is compiled and tests are executed. The MSBuild error prevents the test project from being loaded at all.
+
+**Suspected Root Cause:**
+The root cause of the MSBuild error is likely related to the execution environment where the `dotnet test` command is being run. Potential factors include:
+- **File System Permissions:** The user account running the command may not have sufficient permissions to read the `.csproj` file.
+- **.NET Environment Configuration:** Issues with the .NET SDK installation, environment variables, or NuGet configuration could interfere with MSBuild's ability to locate or process the project file.
+- **External Interference:** Antivirus software, security policies, or other background processes might be temporarily locking or blocking access to the file during the build attempt.
+
+These are issues that require investigation of the specific system environment and user configuration, which cannot be fully diagnosed or resolved through automated tools alone.
+
+**Conclusion:**
+The persistent MSBuild error is preventing the execution of the WalletFramework.Core tests. The issue stems from an inability of the `dotnet test` command (specifically MSBuild) to access or recognize the test project file, despite its physical presence. This points to an environment-specific problem rather than a code-level defect within the WalletFramework.Core library itself or the test project file content.
+
+**Recommendations for Resolution:**
+Human intervention is required to investigate the execution environment. The following steps are recommended:
+1. **Verify File Permissions:** Check the file system permissions for the user account on the file `test/WalletFramework.Core.Tests/WalletFramework.Core.Tests.csproj`. Ensure read access is granted.
+2. **Test Execution Environment:** Attempt to run the `dotnet test` command from a different terminal, potentially with administrator privileges (if appropriate and safe), to rule out terminal-specific or permission issues.
+3. **.NET Environment Check:** Review the .NET SDK installation. Consider running `dotnet --info` to check the installed SDKs and runtimes. Verify relevant environment variables.
+4. **Security Software:** Temporarily disable antivirus or other security software (with caution and awareness of risks) to see if it resolves the issue.
+5. **Repair/Reinstall .NET SDK:** If other steps fail, consider repairing or reinstalling the .NET SDK.
+
+Addressing these environment-specific factors is necessary to resolve the MSBuild error and allow the tests to execute. Once the tests can run, the code-level issues identified in the code comprehension report (missing `DecodeBytes`, incorrect `Decode` calls) can then be addressed if they cause test failures.
\ No newline at end of file
diff --git a/reports/security_audit_report.md b/reports/security_audit_report.md
new file mode 100644
index 00000000..5e36d4c4
--- /dev/null
+++ b/reports/security_audit_report.md
@@ -0,0 +1,39 @@
+# Security Audit Report: CredentialManager and Oid4VpClient
+
+**Date:** 2025-05-20
+
+**Modules Reviewed:**
+- CredentialManager class ([`src/WalletFramework.CredentialManagement/CredentialManager.cs`](src/WalletFramework.CredentialManagement/CredentialManager.cs))
+- Oid4VpClient class ([`src/WalletFramework.Oid4Vp/Oid4VpClient.cs`](src/WalletFramework.Oid4Vp/Oid4VpClient.cs))
+
+**Scope of Review:**
+This audit focused on the provided source code for the `CredentialManager` and `Oid4VpClient` classes. The review included a manual analysis of the code for potential security vulnerabilities, conceptually aligning with Static Application Security Testing (SAST) principles. Due to the minimal implementation and reliance on external services, a full Software Composition Analysis (SCA) or deep SAST was not feasible for the core logic which resides in dependencies. The review also considered the security implications for the required but unimplemented functionalities and dependencies.
+
+**Methods Used:**
+- Manual Code Review: Examination of the source code line by line to identify potential security weaknesses, logical flaws, and areas requiring secure implementation.
+- Conceptual Threat Modeling: Consideration of potential attack vectors and risks associated with credential management and OID4VP presentation flows, even in the absence of full implementation.
+
+**Findings:**
+
+| Severity | Description | Location | Recommendations |
+|---------------|-------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **High** | Use of a "dummy_query" for credential retrieval in `Oid4VpClient`. | [`src/WalletFramework.Oid4Vp/Oid4VpClient.cs:32`](src/WalletFramework.Oid4Vp/Oid4VpClient.cs:32) | Replace the dummy query with robust logic that securely parses the `authorizationRequest` to determine required credentials and queries the `IStorageService` based on validated requirements. Implement strict access controls. |
+| **Informational** | `CredentialManager` class is a placeholder with no functional implementation. | [`src/WalletFramework.CredentialManagement/CredentialManager.cs`](src/WalletFramework.CredentialManagement/CredentialManager.cs) | Implement secure credential management functionalities, including storage, retrieval, and lifecycle management, adhering to secure coding practices and relevant standards (e.g., using secure storage mechanisms). |
+
+**Areas for Future Security Focus (Dependencies):**
+The `Oid4VpClient` relies on `IPresentationService` and `IStorageService`. The security of the overall OID4VP flow is highly dependent on the secure implementation of these services. Critical areas requiring rigorous security review during their implementation include:
+- **Authorization Request Validation:** Comprehensive validation of incoming authorization requests, including signature verification, nonce validation, scope checking, and ensuring alignment with wallet capabilities and user consent.
+- **Presentation Response Creation:** Secure formatting, signing, and potential encryption of the presentation response. Ensuring only authorized and selected credentials/claims are included and properly bound to the proof of possession.
+- **Secure Credential Storage and Retrieval:** Implementing secure mechanisms for storing sensitive credential data and retrieving it based on validated queries, preventing unauthorized access or leakage.
+
+**Risk Rating Explanation:**
+- **High:** Vulnerabilities that could be exploited to cause significant harm, such as unauthorized access to sensitive data (credentials).
+- **Informational:** Not a direct vulnerability, but highlights incomplete or placeholder code that requires secure implementation in the future.
+
+**Conclusion:**
+The security review of the current `CredentialManager` and `Oid4VpClient` classes identified one high-severity vulnerability related to the placeholder credential query in `Oid4VpClient`. The `CredentialManager` is currently a placeholder and requires secure implementation. The overall security of the OID4VP flow is heavily dependent on the secure implementation of the injected services (`IPresentationService` and `IStorageService`).
+
+**Recommendations Summary:**
+- Address the high-severity vulnerability in `Oid4VpClient` by implementing secure credential query logic.
+- Ensure secure implementation of the `CredentialManager` when its functionality is added.
+- Prioritize rigorous security review and secure coding practices during the implementation of `IPresentationService` and `IStorageService`.
\ No newline at end of file
diff --git a/research/analysis/contradictions_part_1.md b/research/analysis/contradictions_part_1.md
new file mode 100644
index 00000000..169696fa
--- /dev/null
+++ b/research/analysis/contradictions_part_1.md
@@ -0,0 +1,23 @@
+# Contradictions - Part 1
+
+This document notes any contradictions or inconsistencies found within the collected research data.
+
+## Edge-Case Functional Tests
+
+- No significant contradictions were identified in the initial data collection regarding edge-case functional tests in .NET JSON and URI handling.
+
+## Concurrency & Thread-Safety
+
+- No significant contradictions were identified in the initial data collection regarding concurrency and thread-safety in .NET. The findings consistently emphasize the need for proper synchronization when dealing with shared resources in multi-threaded environments.
+
+## Negative & Security-Focused Tests
+
+- No significant contradictions were identified in the initial data collection regarding negative and security-focused testing in .NET. The information consistently points to the importance of secure coding practices and utilizing available security features.
+
+## Performance Benchmarks
+
+- No significant contradictions were identified in the initial data collection regarding performance benchmarking in .NET. The findings consistently highlight various serialization methods, optimization techniques, and the impact of data structures on performance.
+
+## Compliance Scenarios
+
+- No significant contradictions were identified in the initial data collection regarding compliance scenarios in .NET. The findings consistently highlight the availability of cryptographic features and configuration options for compliance.
\ No newline at end of file
diff --git a/research/analysis/identified_patterns_part_1.md b/research/analysis/identified_patterns_part_1.md
new file mode 100644
index 00000000..a24b9775
--- /dev/null
+++ b/research/analysis/identified_patterns_part_1.md
@@ -0,0 +1,37 @@
+# Identified Patterns - Part 1
+
+This document outlines patterns and recurring themes identified during the analysis of the collected research data.
+
+## Edge-Case Functional Tests
+
+- **Configurability of .NET Components:** .NET provides extensive configuration options for core components like JSON serializers and URI handlers, allowing customization of behavior for various scenarios, including some edge cases (e.g., null handling, case sensitivity).
+- **Importance of Serialization Options:** The behavior of JSON serialization and deserialization in edge cases is heavily dependent on the configured `JsonSerializerOptions`, highlighting the need for careful consideration and testing of these options.
+- **Error Handling for Invalid Input:** .NET's built-in JSON handling throws specific exceptions (`JsonException`) for certain types of invalid input, which can be leveraged for testing error handling mechanisms.
+
+## Concurrency & Thread-Safety
+
+- **Rich .NET Concurrency Features:** The .NET framework offers a wide array of built-in features for managing concurrency and parallelism, including dedicated concurrent collection types and low-level synchronization primitives.
+- **Importance of Explicit Synchronization:** Despite the availability of concurrent features, many .NET objects and operations are not inherently thread-safe, necessitating explicit synchronization mechanisms (like `lock` or `Interlocked`) when accessed from multiple threads to prevent race conditions and ensure data integrity.
+- **Potential for Deadlocks and Race Conditions:** Improper implementation of parallel operations and synchronization can easily lead to common concurrency issues like deadlocks and race conditions, highlighting the critical need for careful design and testing in multi-threaded scenarios.
+- **Tools Available for Analysis:** .NET provides profiling tools like Concurrency Visualizer to help identify and diagnose concurrency-related issues in applications.
+
+## Negative & Security-Focused Tests
+
+- **Emphasis on Secure Coding Practices:** The .NET documentation and code analysis rules highlight the importance of secure coding practices to prevent common vulnerabilities like injection attacks, weak cryptography, and insecure handling of sensitive data.
+- **Built-in Security Features:** .NET provides built-in features and tools for security-related tasks, including secure random number generation, certificate management, and security auditing of dependencies.
+- **Need for Specific Vulnerability Testing:** While general secure coding principles are covered, effectively testing for specific web vulnerabilities like CSRF and XSS requires dedicated strategies and tools beyond basic input sanitization.
+- **Importance of Cryptography and Certificate Handling:** Secure handling of cryptographic operations, including using strong algorithms and properly validating certificates, is a recurring theme in the security documentation.
+
+## Performance Benchmarks
+
+- **Variety of Serialization Options:** .NET offers multiple serialization approaches (JSON, XML, DataContract) with different performance characteristics, allowing developers to choose the most suitable one for their needs.
+- **Tools and Techniques for Performance Improvement:** Specific tools (`XmlSerializerGenerator`) and techniques (streaming deserialization) are available to address performance bottlenecks in serialization and deserialization, particularly for large data.
+- **Impact of Data Structures and Operations:** The choice of data structures (collections) and fundamental operations (string manipulation) can significantly influence application performance.
+- **Benchmarking as a Key Practice:** The existence of benchmarking examples and tools in the documentation implies that performance measurement is a recognized and important practice in .NET development.
+
+## Compliance Scenarios
+
+- **Availability of Cryptography Primitives:** .NET provides a comprehensive set of cryptographic primitives and algorithms necessary for implementing secure and compliant applications.
+- **Configuration for Cryptographic Behavior:** .NET offers configuration options to influence cryptographic behavior, including enabling strong cryptography and managing FIPS mode, which are crucial for meeting compliance requirements.
+- **Cross-Platform Considerations:** Cryptography support can vary across platforms, necessitating careful consideration when developing cross-platform compliant applications.
+- **Tools for Data Compliance:** Features like data classification and redaction are available to assist with compliance requirements related to handling sensitive information.
\ No newline at end of file
diff --git a/research/analysis/knowledge_gaps.md b/research/analysis/knowledge_gaps.md
new file mode 100644
index 00000000..a35ba3c6
--- /dev/null
+++ b/research/analysis/knowledge_gaps.md
@@ -0,0 +1,31 @@
+# Knowledge Gaps
+
+This document outlines the areas where the current research has insufficient information and requires further investigation. These gaps will inform subsequent targeted research cycles.
+
+## Edge-Case Functional Tests - Identified Gaps
+
+- **Oversized Payloads:** The initial research did not yield specific guidance or best practices for handling excessively large JSON payloads or URIs in .NET applications, particularly within the context of the wallet framework's performance and security requirements. Further research is needed to understand potential vulnerabilities or performance degradation associated with oversized inputs and how to effectively test for these scenarios.
+- **Invalid Credential Configurations:** While the concept of testing invalid configurations is mentioned in the blueprint, the initial research did not provide concrete examples or a comprehensive list of what constitutes an "invalid credential configuration" within the specific domain of the wallet framework (OID4VC, mDoc, SD-JWT). Targeted research is required to define these invalid states precisely to inform the creation of relevant test cases.
+
+## Concurrency & Thread-Safety - Identified Gaps
+
+- **Parallel Wallet Operations Testing:** The research provided general information on .NET concurrency features and pitfalls, but lacked specific strategies, patterns, or examples for effectively testing parallel wallet record operations against an in-memory store. Further research is needed to determine appropriate testing methodologies and tools for this specific scenario.
+- **Race Condition Testing in PaymentTransactionDataSamples:** The blueprint specifically mentions testing race conditions on `PaymentTransactionDataSamples`. The initial research provided general information on race conditions and synchronization, but did not offer concrete examples or approaches for identifying and testing race conditions within this specific component or similar data structures used in the wallet framework. Targeted research is required to develop effective test cases for these scenarios.
+
+## Negative & Security-Focused Tests - Identified Gaps
+
+- **Tampered Tokens and Replayed Requests Testing:** The research provided general information on security tokens but lacked specific guidance and techniques for testing against tampered JSON Web Tokens (JWTs) and replayed HTTP requests within the context of the wallet framework's communication protocols (OID4VC, etc.). Further research is needed to understand common attack vectors and effective testing strategies for these scenarios.
+- **Comprehensive CSRF/XSS Testing:** While basic input sanitization was mentioned, the research did not provide comprehensive strategies, tools, or .NET-specific guidance for conducting thorough CSRF (Cross-Site Request Forgery) and XSS (Cross-Site Scripting) checks, particularly relevant for any cookie-based authentication flows the wallet framework might utilize.
+- **FIPS Compliance for Cryptography:** The research highlighted the importance of using cryptographically secure random number generators, but lacked detailed information on the specific steps, configurations, or verification processes required to ensure the wallet framework's cryptographic operations are fully compliant with FIPS standards.
+- **SD-JWT Selective Disclosure Edge Cases:** The research provided no information regarding SD-JWT selective disclosure edge cases, especially concerning the implications and testing of maximum nested claims. This is a significant knowledge gap requiring dedicated research into the SD-JWT specification and related testing methodologies.
+
+## Performance Benchmarks - Identified Gaps
+
+- **Bulk Serialization/Deserialization Benchmarking:** The research provided general information on .NET serialization performance and optimization techniques, but lacked specific strategies, tools, or examples for benchmarking the performance of bulk serialization and deserialization of a large number of records (e.g., 1000), which is a key performance benchmark identified in the blueprint.
+- **High-Throughput Issuance Simulation:** The research did not provide information or strategies for designing and implementing a simulation of high-throughput credential issuance for performance testing within the wallet framework. This is a knowledge gap that needs to be addressed to effectively benchmark this critical operation.
+
+## Compliance Scenarios - Identified Gaps
+
+- **OID4VC, mDoc, and SD-JWT Cryptographic Compliance:** The research provided general information on .NET cryptography features but lacked specific details on the cryptographic algorithms, key sizes, and protocol requirements mandated by the OID4VC, mDoc, and SD-JWT specifications. Further research is needed to ensure the wallet framework's cryptographic implementations align with these standards.
+- **FIPS Compliance Verification for Wallet Framework:** While .NET's FIPS mode configuration was mentioned, the research did not provide concrete steps, tools, or verification methods specifically for ensuring and demonstrating FIPS compliance of the wallet framework's cryptographic modules and operations.
+- **SD-JWT Selective Disclosure Compliance Aspects:** The research provided no information on the specific compliance requirements or testing methodologies related to SD-JWT selective disclosure, including how to ensure compliance when handling and verifying selectively disclosed claims, especially in complex scenarios with nested claims. This is a significant knowledge gap requiring dedicated research into the SD-JWT specification and compliance testing.
\ No newline at end of file
diff --git a/research/data_collection/expert_insights_part_1.md b/research/data_collection/expert_insights_part_1.md
new file mode 100644
index 00000000..4aba9b80
--- /dev/null
+++ b/research/data_collection/expert_insights_part_1.md
@@ -0,0 +1,47 @@
+# Expert Insights - Part 1
+
+This document summarizes expert opinions, recommendations, and best practices relevant to the research areas.
+
+## Edge-Case Functional Tests
+
+- **JSON Handling:**
+ - Disabling `TypeNameHandling` in `JsonSerializer` is recommended to prevent potential deserialization security risks. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca2330.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca2330.md#2025-04-21_snippet_0))
+
+- **Testing:**
+ - Configuration options are available for testing frameworks like MSTest to control execution behavior and assembly resolution. (Source: [https://github.com/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-configure.md#2025-04-21_snippet_7](https://github.com/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-configure.md#2025-04-21_snippet_7), [https://github.com/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-configure.md#2025-04-21_snippet_3](https://github.com/dotnet/docs/blob/main/docs/core/testing/unit-testing-mstest-configure.md#2025-04-21_snippet_3))
+
+## Concurrency & Thread-Safety
+
+- **Utilize Thread-Safe Collections:** Employ concurrent collection classes (`ConcurrentDictionary`, `ConcurrentQueue`, etc.) for managing data accessed by multiple threads to avoid manual synchronization overhead.
+- **Employ Synchronization Primitives Judiciously:** Use low-level synchronization primitives (`lock`, `SemaphoreSlim`, `Barrier`, etc.) for fine-grained control when concurrent collections are not suitable, but be mindful of potential performance impacts and complexities.
+- **Avoid Unsafe Access to Non-Thread-Safe Objects:** Do not access or modify instances of classes that are not designed for concurrent use (like `FileStream` or certain SDK model objects) from multiple threads without implementing proper synchronization mechanisms.
+- **Guard Against Race Conditions:** Implement synchronization when caching security checks or handling resource cleanup (`Dispose`) to prevent race conditions that could lead to vulnerabilities or incorrect behavior.
+- **Beware of Deadlocks:** Design parallel operations carefully to avoid situations where threads are waiting indefinitely for each other, particularly in parallel loops or when using synchronization events. Avoid blocking the UI thread with parallel operations that require UI updates.
+- **Use Atomic Operations for Simple Updates:** For simple, atomic updates to shared variables (like counters), prefer using `Interlocked` class methods over locking for better performance.
+- **Leverage Profiling Tools:** Utilize tools like Concurrency Visualizer to analyze the runtime behavior of concurrent applications, identify performance bottlenecks, and detect potential threading issues.
+
+## Negative & Security-Focused Tests
+
+- **Use Cryptographically Secure RNG:** Always use `System.Security.Cryptography.RandomNumberGenerator` for security-sensitive operations requiring random numbers. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5394.md#2025-04-21_snippet_3](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5394.md#2025-04-21_snippet_3))
+- **Avoid Weak Cryptography:** Do not use outdated or weak cryptographic algorithms or key derivation functions. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5373.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5373.md#2025-04-21_snippet_1))
+- **Sanitize User Input:** Implement robust input sanitization to prevent injection attacks like XSS. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/security/security-and-user-input.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/standard/security/security-and-user-input.md#2025-04-21_snippet_0))
+- **Secure XML Processing:** Configure XML readers securely (`XmlResolver = null` or `XmlSecureResolver`) to mitigate the risk of external entity attacks. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca3075.md#2025-04-21_snippet_9](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca3075.md#2025-04-21_snippet_9))
+- **Validate Certificates:** Ensure proper certificate validation, including checking revocation lists, when establishing secure connections. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5400.md#2025-04-21_snippet_2](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5400.md#2025-04-21_snippet_2))
+- **Use Enumeration Names for Security Protocols:** Avoid hardcoding integer values for security protocols; use the defined enumeration names for clarity and maintainability. (Source: [https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5386.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca5386.md#2025-04-21_snippet_1))
+- **Leverage Security Auditing Tools:** Utilize tools like NuGet package vulnerability auditing to identify known security issues in dependencies.
+
+## Performance Benchmarks
+
+- **Choose Appropriate Serialization Method:** Select the serialization method (`System.Text.Json`, `XmlSerializer`, `DataContractSerializer`) based on performance requirements and data format. `System.Text.Json` is generally recommended for modern .NET applications due to its performance and memory efficiency.
+- **Optimize Serialization Startup:** For XML serialization, consider using `XmlSerializerGenerator` to pre-generate serialization assemblies and improve startup performance. (Source: [https://github.com/dotnet/docs/blob/main/docs/core/additional-tools/index.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/core/additional-tools/index.md#2025-04-21_snippet_0))
+- **Employ Streaming for Large Data:** When dealing with large datasets, particularly JSON arrays, use streaming deserialization (`DeserializeAsyncEnumerable`) to avoid excessive memory consumption. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/supported-types.md#2025-04-21_snippet_2](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/supported-caught-exceptions.md#2025-04-21_snippet_0))
+- **Consider Collection Performance Characteristics:** Be mindful of the performance implications of different collection types and choose the most suitable one for the specific use case.
+- **Benchmark Critical Operations:** Identify performance-critical operations (like serialization/deserialization and data processing) and implement benchmarks to measure and track their performance.
+
+## Compliance Scenarios
+
+- **Configure Strong Cryptography:** Ensure that the application is configured to use strong cryptographic protocols, potentially through registry settings or application context switches. (Source: [https://github.com/dotnet/docs/blob/main/docs/framework/network-programming/tls.md#2025-04-21_snippet_5](https://github.com/dotnet/docs/blob/main/docs/framework/network-programming/tls.md#2025-04-21_snippet_5))
+- **Use Recommended Cryptography Classes:** Utilize the recommended .NET cryptography classes for digital signatures, public-key encryption, and hashing, avoiding outdated or weak implementations. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_3](https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_3), [https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_2](https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_2), [https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_4](https://github.com/dotnet/docs/blob/main/docs/standard/security/cryptographic-services.md#2025-04-21_snippet_4))
+- **Understand Cross-Platform Cryptography Support:** Be aware of the differences in cryptography support across different operating systems and .NET versions, especially concerning RSA padding modes and digest algorithms. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/security/cross-platform-cryptography.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/standard/security/cross-platform-cryptography.md#2025-04-21_snippet_0))
+- **Manage FIPS Mode Behavior:** Configure the application's behavior in FIPS mode using `AppContextSwitchOverrides` to ensure compliance requirements are met. (Source: [https://github.com/dotnet/docs/blob/main/includes/migration-guide/retargeting/core/managed-cryptography-classes-do-not-throw-cryptographyexception-fips-mode.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/includes/migration-guide/retargeting/core/managed-cryptography-classes-do-not-throw-cryptographyexception-fips-mode.md#2025-04-21_snippet_1))
+- **Leverage Data Classification and Redaction:** Utilize .NET's data classification and redaction features to help meet compliance requirements related to handling sensitive data. (Source: [https://github.com/dotnet/docs/blob/main/docs/core/extensions/compliance.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/core/extensions/compliance.md#2025-04-21_snippet_0))
\ No newline at end of file
diff --git a/research/data_collection/primary_findings_part_1.md b/research/data_collection/primary_findings_part_1.md
new file mode 100644
index 00000000..507a4ac4
--- /dev/null
+++ b/research/data_collection/primary_findings_part_1.md
@@ -0,0 +1,89 @@
+# Primary Research Findings - Part 1
+
+This document contains direct findings and key data points gathered during the research process.
+
+## Edge-Case Functional Tests
+
+- **JSON Handling:**
+ - .NET's `System.Text.Json` provides options for handling JSON serialization and deserialization.
+ - `JsonSerializerOptions` can be configured for case-insensitive property matching (`PropertyNameCaseInsensitive = true`). (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/character-casing.md#_snippet_0](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/character-casing.md#_snippet_0))
+ - Null values can be ignored during serialization using `DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull` or `[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]` on properties. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/migrate-from-newtonsoft.md#_snippet_7](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/migrate-from-newtonsoft.md#_snippet_7), [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/migrate-from-newtonsoft.md#_snippet_8](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/migrate-from-newtonsoft.md#_snippet_8))
+ - Deserialization can throw `JsonException` for invalid JSON, such as properties starting with '$' in types supporting metadata or mismatched key/value pairs with specific options. (Source: [https://github.com/dotnet/docs/blob/main/docs/core/compatibility/serialization/9.0/json-metadata-reader.md#2025-04-21_snippet_2](https://github.com/dotnet/docs/blob/main/docs/core/compatibility/serialization/9.0/json-metadata-reader.md#2025-04-21_snippet_2), [https://github.com/dotnet/docs/blob/main/docs/core/compatibility/serialization/5.0/options-honored-when-serializing-key-value-pairs.md#2025-04-21_snippet_2](https://github.com/dotnet/docs/blob/main/docs/core/compatibility/serialization/5.0/options-honored-when-serializing-key-value-pairs.md#2025-04-21_snippet_2))
+ - Handling of quoted numbers in JSON can be configured. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/invalid-json.md#2025-04-21_snippet_3](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/invalid-json.md#2025-04-21_snippet_3))
+ - Comments and trailing commas are generally invalid in standard JSON but might be handled by some parsers. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/invalid-json.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/invalid-json.md#2025-04-21_snippet_0))
+ - Serialization of null for non-nullable reference types with `RespectNullableAnnotations = true` can throw `JsonException`. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/nullable-annotations.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/standard/serialization/system-text-json/nullable-annotations.md#2025-04-21_snippet_0))
+
+- **URI Handling:**
+ - URI handling behavior can be configured in .NET, including disabling URI redaction. (Source: [https://github.com/dotnet/docs/blob/main/docs/core/compatibility/networking/9.0/query-redaction-events.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/docs/core/compatibility/networking/9.0/query-redaction-events.md#2025-04-21_snippet_1), [https://github.com/dotnet/docs/blob/main/docs/core/compatibility/networking/9.0/query-redaction-logs.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/docs/core/compatibility/networking/9.0/query-redaction-logs.md#2025-04-21_snippet_1), [https://github.com/dotnet/docs/blob/main/docs/framework/configure-apps/file-schema/network/uri-element-uri-settings.md#2025-04-21_snippet_0](https://github.com/dotnet/docs/blob/main/docs/framework/configure-apps/file-schema/network/uri-element-uri-settings.md#2025-04-21_snippet_0))
+ - Configuration for URI handling can be done via `runtimeconfig.json` or project files.
+
+- **Invalid Credential Configurations:**
+ - The search results did not provide specific details on invalid credential configurations within the context of a wallet framework. This is a knowledge gap.
+
+- **Oversized Payloads:**
+ - The search results did not provide specific details on handling oversized payloads for JSON or URIs. This is a knowledge gap.
+
+## Concurrency & Thread-Safety
+
+- **Synchronization Primitives:** .NET provides low-level synchronization primitives like `Barrier`, `CountdownEvent`, `ManualResetEventSlim`, `SemaphoreSlim`, `SpinLock`, and `SpinWait` for coordinating threads. (Source: [https://github.com/dotnet/docs/blob/main/docs/standard/parallel-programming/data-structures-for-parallel-programming.md#2025-04-21_snippet_1](https://github.com/dotnet/docs/blob/main/docs/standard/parallel-programming/data-structures-for-parallel-programming.md#2025-04-21_snippet_1))
+- **Concurrent Collections:** Thread-safe collection classes such as `BlockingCollection