Will EDVs and Hubs use the same authorization protocol standard?
Our Confidential Storage process seems driven by a handful of implementers with use-cases that I don't understand. This makes it hard for someone like myself that is concerned about human-centric interoperability, zero-trust architectures, or substitutability and competition across service providers.
I don't understand, in human or use-case terms, why we're partitioning the Confidential Storage space into EDVs and Hubs. You don't owe me an explanation but it's hard for me to feel constructive if I'm lost.
So here's my question in a more technical framing: Will EDVs and Hubs use the same authorization protocol standard? In other words, are Hubs going to be clients of EDVs or peers with EDVs when it comes to a human-centered authorization server?
The use-case I'm concerned with is delegation by a resource owner (data subject) to a semi-autonomous agent. This agent uses HTTP protocols to convert resource requests (a triplet of credentials, scope, and purpose) into authorization tokens or capabilities to be used at various service providers - the 250 service providers in my password manager. The service providers should be readily substitutable with a minimum of disruption in order to avoid vendor or platform lock-in.
This delegated authorization server will issue tokens / capabilities to three kinds of service providers:
- providers that have plain text data and may produce or consume documents, streams or VCs to authorized clients,
- providers that have encrypted data in JWE format and encrypted indexes to be written or read by authorized clients,
- providers that look like directories or mediators and act as data brokers between clients authorized by me and by others.
From my user perspective, the same service provider could offer me a mix of data and index features. For example, my hospital could keep my allergies and vaccination status as plain text but encrypt my psychiatric notes in such a way that they could only be read with my consent by other authorized psychiatrists and, importantly, not read by me.
Another example, my school might offer to share my contact info with authorized clients but shere my letters of recommendation only with requesting parties that bring specific credentials. I would not be allowed to see these letters.
The addition of discovery to the service provider repertoire also highlights the human perspective on this issue. As a resource owner (data subject) I want to control discovery of my authorization server because processing requests is costly in many ways. As such, I will store some data where it can be indexed, searched, and discovered without explicit authorization. This directory service is then effectively acting as my agent with some policies that determine if and when to contact my authorization server or refer a requesting party to my authorization server. In this case, I do not want the directory to ever access the data itself.