If you read our last blog post, you’ll know that the Innovation Lab spent much of 2023 engaging with other consortium members to test the Data Rights Protocol (DRP). This post covers the what and the why behind various flavors of testing: conformance, integration, and interoperability testing.
Testing the Data Rights Protocol requires the involvement of multiple parties:
- Authorized Agents (AA) – entities authorized by consumers to submit data opt out of sale and deletion requests to businesses. Permission Slip is one such agent, although there are others in the consortium like Yorba, Incogni, and Mine.
- Privacy Infrastructure Providers (PIP) – B2B entities that provide data processing services and infrastructure to help businesses action consumer data requests. PIPs help ensure that companies are in compliance with privacy laws. OneTrust, Transcend, DataGrail, Ethyca, and WireWheel participate in the DRP consortium as PIPs.
- Covered Business (CB) – businesses that wield consumer data and thus need to comply with consumer privacy laws. Many CBs rely on manual processes to action requests, and are attracted to the DRP for its ability to modernize and help scale their current processes, making them faster, cheaper, and more efficient.
Each party has a role to play in ensuring the delivery and actioning of data rights requests that consumers send. We designed a testing sequence that involves each of these parties and moves through a standard progression to ensure conformance and interoperability. These tests begin small, focusing on one-on-one request exchange with individual partners, then grow to include many different actors working together as a network.
Conformance Testing
Conformance testing ensures that consortium members have met all requirements of the protocol in their implementations. To test conformance of different DRP implementations, we use OSIRAA (Open Source Implementers’ Reference Authorized Agent). OSIRAA takes on the role of an AA, modeling the transmission of data requests to the PIP, and evaluates the responses for correctness. We’ve also developed a companion tool, OSIRPIP (Open Source Implementers’ Reference of a Privacy Infrastructure Provider) as a module inside OSIRAA so that authorized agents participating in the consortium can test their DRP implementations against a mock Privacy Infrastructure Provider.
Once conformance is confirmed, we advance to a partial end to end, or 1×1 test. Here an AA and PIP test the protocol endpoints in pairs, using synthetic data. Issues that arise are corrected before proceeding to the next step.
Integration Testing
After a successful 1×1 test, we’re ready to move to a 1x1x1 test. This is a full end to end test, where a sample request is sent from the AA to the PIP and onwards to the covered business. It’s an integration test because CBs who use a PIP will integrate DRP through a configuration in their PIP software. This represents an entire lifecycle of one request end-to-end, including status updates that cascade through the network.
Of course, some covered businesses don’t rely on privacy infrastructure providers for request processing. In those cases, the CB assumes the role of PIP and will be able to satisfy conformance via a regular 1×1 test.
Interoperability Testing
With the request lifecycle completed, we proceed to interoperability testing. The purpose of the interoperability test is to verify compatibility and consistent communication between different parties’ DRP implementations.
This is where we reach a 2×2 test: so named because it features not one, but two AA’s and PIP’s. It checks if an Authorized Agent can discover, route to, and exchange data requests with more than one PIP and, conversely, that a PIP can receive and respond to data rights requests from more than one AA.
When the 2×2 test is complete, we arrive at the final phase of testing: extending the network to include the covered businesses themselves. We call this test many x many x many because it represents a multi-party network emblematic of the data rights ecosystem the protocol envisions: many agents sending many requests to multiple PIP’s and onwards to many CBs. The key difference in this case is that all the data rights requests are running on the same set of rails and conforming with the same set of rules.
Our partners at Yorba, Transcend, and OneTrust are currently working to implement the DRP to reach the 2×2 milestone alongside the Permission Slip team. From there, we’ll release v1.0 of the Data Rights Protocol and invite Covered Businesses’ into the fold as users.
In addition to passing through this gauntlet of testing, 1.0 will require governance documents and operative rules – a topic for a future blog post.
Acknowledgements
Thanks to Ryan Rix, Dazza Greenwood, and John Szinger for their work to develop this testing progression and associated tooling, and to Ginny Fahs for editing this post.
