search

decentralized-identity / confidential-storage

Confidential Storage Specification and Implementation
https://identity.foundation/confidential-storage/
Apache License 2.0
80 stars 24 forks source link

Use Case for filtering response based on consent #205

Open neiljthomson opened 3 years ago

neiljthomson commented 3 years ago

While the core use cases cover only returning data items based on consent, while I suspect I am not looking hard enough, I don't see a requirement/use case for filtering data returned to a requester based on consent by the data owner (e.g., you can only have de-identified data vs. returning all the properties in my medical records).

While such a filtering service may be in the "client" of the client/server model (as I understand it - and is admittedly limited at this point) vs. the EDV server) or in an associated Data Hub, there surely are requirements that need to be specified in how this filtering can take place without leaking information (e.g., do the filtering in an sandbox within the EDV server/client or Data Hub vs. decrypting, transferring then filtering).

agropper commented 3 years ago

I find it useful to frame issues related to consent in terms of policy decision points (PDP) and policy enforcement points (PEP). This issue seems to be about whether the policies of the PDP are visible to the PEP. This issue is the same regardless of whether the authorization model is capabilities or ACL. To the extent the resource owner (RO) controls the policies and also controls the structure of resources protected by the PEP, it would be up to the RO to design the structure, and therefore the filtering options for resources in storage.

From this perspective, this issue is out of scope for EDVs.

That said, an EDV that was particularly clever (or evil) could guess that it was storing FHIR-structured health records and then, based on traffic analysis, decode which component of a health record was being requested when and by which clients. A concerned resource owner would apply herd immunity principles to mitigate this risk. They might bundle the whole FHIR health record into one document and do the filtering client-side. They might introduce a mediator role in order to obscure the network address and other fingerprints of the client.

neiljthomson commented 3 years ago

Can't disagree with the arguments on PDP vs. PEP, but that still leaves a vital service - filtering personally sensitive data based on consent to 3rd parties in a secure (encrypted?) manner - in limbo based on the current Confidential Storage model.

Either this issue needs to find a "home" for where this service is provided in a secure manner or the Confidential Storage model has a major acceptance problem from a user and (likely) privacy legislative perspective.

The "mediator" role suggests a solution, but it's currently not in anybody's model of this type of interaction.

Perhaps this is a EDV client or Identity Secured Data Hub service (vs. EDV service)?