Enhanced Verification: Object-Based Credential Checks

In the ever-evolving landscape of digital credentials and verifiable presentations, flexibility and control are paramount. A recent discussion has centered around enhancing the way verification checks are handled, specifically concerning the checks parameter used in verification processes like /presentations/verify. The current implementation primarily accepts an array of strings, where each string signifies a specific check to be performed. However, this approach has limitations, particularly when it comes to disabling default checks.

The Current Challenge with Array-Based Checks

The existing array-based system operates on the principle that if a string representing a check is present in the array, that check should be enabled. This works well for adding checks that are not enabled by default. However, it creates a significant hurdle when the goal is to disable a check that is enabled by default. Because the mere presence of the check's identifier in the array triggers its execution, there's no straightforward way to opt-out. This is a critical issue because it restricts the verifier's ability to customize the verification process according to their specific needs and trust model. For instance, the default behavior might include checking the credential status, which involves consulting external registries or revocation lists. While this is a valuable security measure in many scenarios, it may not be necessary or feasible in all cases. A verifier might have alternative means of assessing the credential's validity, or the infrastructure required for status checks might be unavailable. In such situations, the inability to disable the default check becomes a bottleneck, hindering the verification process.

Proposing an Object-Based Solution for Verification Checks

To address the limitations of the array-based approach, the proposal suggests allowing the checks parameter to accept an object with key-value pairs, where the keys represent the checks and the values are boolean flags indicating whether the check should be enabled or disabled. This object-based approach offers a more explicit and intuitive way to control the verification process. Each check can be individually configured, providing granular control over which checks are performed. This is particularly beneficial for disabling default checks, as the verifier can simply set the corresponding value to false. For example, to disable the credential status check, the checks object might look like this:

{
  "credentialStatus": false
}

This clearly indicates that the credential status check should not be performed, regardless of whether it's enabled by default. The object-based approach also enhances the readability and maintainability of the verification configuration. It provides a clear and structured way to define the desired checks, making it easier to understand and modify the configuration as needed. Furthermore, it opens up possibilities for more advanced verification scenarios, where checks might be conditionally enabled or disabled based on other factors, such as the type of credential being verified or the context of the verification.

Benefits of the Object-Based Approach

• Granular Control: Enables precise control over individual checks.
• Disabling Default Checks: Provides a mechanism to disable checks that are enabled by default.
• Improved Readability: Offers a clear and structured configuration format.
• Enhanced Flexibility: Supports more advanced verification scenarios.

Implementation Considerations for Object-Based Verification

Implementing the object-based approach requires careful consideration to ensure backward compatibility and avoid disrupting existing workflows. One approach is to allow both the array-based and object-based formats for the checks parameter. If an array is provided, the existing behavior would be preserved, with each string in the array indicating a check to be enabled. If an object is provided, the key-value pairs would be used to configure the checks, with boolean values indicating whether each check should be enabled or disabled. This would allow existing users to continue using the array-based format without modification, while providing new users with the flexibility of the object-based approach. Another consideration is how to handle conflicts between the array-based and object-based configurations. For example, if a check is included in the array and also explicitly disabled in the object, which setting should take precedence? A reasonable approach would be to prioritize the object-based configuration, as it provides a more explicit and intentional setting. However, this should be clearly documented to avoid confusion. Furthermore, the implementation should include thorough validation to ensure that the checks object is well-formed and contains valid check identifiers. This would help prevent errors and ensure that the verification process is configured correctly.

Technical Details and Code Examples

To illustrate the implementation, consider a hypothetical verification function:

async function verifyPresentation(presentation, checks) {
  let enabledChecks = {};

  if (Array.isArray(checks)) {
    // Array-based configuration
    checks.forEach(check => {
      enabledChecks[check] = true;
    });
  } else if (typeof checks === 'object' && checks !== null) {
    // Object-based configuration
    for (const check in checks) {
      if (checks.hasOwnProperty(check)) {
        enabledChecks[check] = checks[check];
      }
    }
  } else {
    // Default configuration (all checks enabled)
    enabledChecks = {
      "credentialStatus": true,
      "revocationStatus": true,
      // Add other default checks here
    };
  }

  // Perform the enabled checks
  if (enabledChecks["credentialStatus"]) {
    await checkCredentialStatus(presentation);
  }

  if (enabledChecks["revocationStatus"]) {
    await checkRevocationStatus(presentation);
  }

  // ... perform other checks
}

In this example, the verifyPresentation function accepts a presentation and a checks parameter. The function first determines whether the checks parameter is an array or an object. If it's an array, it iterates over the array and sets the corresponding keys in the enabledChecks object to true. If it's an object, it iterates over the key-value pairs and sets the corresponding keys in the enabledChecks object to the specified boolean values. If the checks parameter is neither an array nor an object, it assumes the default configuration, where all checks are enabled. Finally, the function performs the enabled checks based on the enabledChecks object. This is a simplified example, but it illustrates the basic principles of implementing the object-based approach. In a real-world implementation, more sophisticated error handling, validation, and configuration options would be required.

Impact on the Bedrock VC Verifier

The Bedrock VC Verifier, as a prominent tool in the verifiable credentials ecosystem, stands to benefit significantly from this enhancement. By adopting the object-based approach for verification checks, the Bedrock VC Verifier can provide its users with greater flexibility and control over the verification process. This would allow users to tailor the verification process to their specific needs and trust models, improving the overall usability and effectiveness of the verifier. Furthermore, the improved readability and maintainability of the configuration would simplify the management of verification policies, reducing the risk of errors and ensuring consistent verification results. The Bedrock VC Verifier can also leverage the enhanced flexibility to support more advanced verification scenarios, such as selectively enabling or disabling checks based on the type of credential being verified or the context of the verification. This would make the Bedrock VC Verifier a more versatile and powerful tool for working with verifiable credentials.

Conclusion: Embracing Flexibility in Verification

In conclusion, allowing the checks parameter to accept an object with key-value pairs, in addition to the existing array-based format, represents a significant improvement in the flexibility and control of verification processes. This enhancement enables verifiers to disable default checks, customize the verification process to their specific needs, and improve the readability and maintainability of the configuration. By embracing this object-based approach, the verifiable credentials ecosystem can move towards a more adaptable and user-friendly future.

To further explore the concepts and standards related to verifiable credentials, consider visiting the W3C Verifiable Credentials Working Group website.