Human story for encrypted data vault. Will fx issue #107

[philarcher]

I love this rewrite.

---

Preview | Diff

[agropper]

I find this confusing. If Maria moves Alice's basket to a new EDV, Alice's endpoint for accessing her basket will change. Specifically, "...and without any of her customers needing to change a thing..." confuses me because Alice would have to change her access endpoint even if her DID that controls an encryption key stays the same.

Adrian

On Mon, Nov 2, 2020 at 3:14 PM Orie Steele notifications@github.com wrote:

@OR13 approved this pull request.

@philarcher https://github.com/philarcher thanks, this is excellent.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/116#pullrequestreview-521960382, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YITDMFAB2BVK73BN3LSN4HJDANCNFSM4TH4VTRQ .

[dlongley]

@agropper,

Specifically, "...and without any of her customers needing to change a thing..." confuses me because Alice would have to change her access endpoint even if her DID that controls an encryption key stays the same.

Clearly, Alice (Maria here) does have to change storage providers because that's a main point in the story, however, the use case implies that her customers wouldn't have to get involved in the details of her change, as the technology handles this for them.

[OR13]

@agropper

The fact that the endpoint changes, does not change the content available at the endpoint.

For example:

https://ipfs.io/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5

https://example.ipfs.io/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5

If QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5 represented encrypted content, it must still be retrieved and decrypted before it can be used.

[agropper]

I understand that the EDV content available at the endpoint does not change. What I'm saying is that Alice needs to actively somehow tell whatever business has registered EDV endpoint 1 that she is moving her content to endpoint 2. The only way to avoid that is for Alice to have registered a mediator with all of her various businesses and then she just has to change the EDV pointer in one place, the mediator.

On Wed, Nov 4, 2020 at 9:39 AM Orie Steele notifications@github.com wrote:

@agropper https://github.com/agropper

The fact that the endpoint changes, does not change the content available at the endpoint.

For example:

https://ipfs.io/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5

https://example.ipfs.io/ipfs/QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5

If QmUQAxKQ5sbWWrcBZzwkThktfUGZvuPQyTrqMzb3mZnLE5 represented encrypted content, it must still be retrieved and decrypted before it can be used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/116#issuecomment-721770323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YOB4KRCI253QX6D5VDSOFRSFANCNFSM4TH4VTRQ .

[OR13]

@agropper it depends... software might handle that automatically. the purpose of this story is to provide a human explanation of EDVs, not to describe the software / authorization updates needed to implement the story.... I would find it hard to explain that simply without introducing agents, authorization servers, or DID URLs, which are all potential solutions to this problem.

[agropper]

Sure, but please change the wording that says that Alice "...wouldn't have to change a thing."

On Wed, Nov 4, 2020 at 10:01 AM Orie Steele notifications@github.com wrote:

@agropper https://github.com/agropper it depends... software might handle that automatically. the purpose of this story is to provide a human explanation of EDVs, not to describe the software / authorization updates needed to implement the story.... I would find it hard to explain that simply without introducing agents, authorization servers, or DID URLs, which are all potential solutions to this problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/116#issuecomment-721783175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YO2VCHDHVK45DAMDWTSOFUDJANCNFSM4TH4VTRQ .

[philarcher]

If in doubt, take it out... I've amended the last sentence to read "When she changes cloud providers, Maria is able to easily and simply migrate all of the data, encrypted and without exposing any data, while the system just continues to work with the new data store." Hope this is OK?

[agropper]

I don’t think “continues to work” is correct. It’s the same issue as before. Maria (the merchant) is in control of where the EDV is hosted but Alice is in control of the encryption keys to her individual basket. That provides confidentiality to both Maria and Alice. Period.

If Maria moves the EDV Alice will lose control of her basket because she can’t reach it. Therefore, Maria will need to notify Alice and everyone of her other customers that their basket is at a new EDV location. That could be a public notice such as a change to Maria’s privacy policy.

If that is the intent of this use-case, then the protocol for accessing an EDV might include a .wellknown thingy so that Maria can publish the EDV location in an interoperable way.

It seems like this use case is leading us to content-addressable storage. That would allow Maria to move the EDV anywhere and anytime without Alice having to change a thing. This, however has nothing to do with confidentiality and applies equally to EDV as well as plaintext vaults.

On Thu, Nov 5, 2020 at 7:11 AM Phil Archer notifications@github.com wrote:

If in doubt, take it out... I've amended the last sentence to read "When she changes cloud providers, Maria is able to easily and simply migrate all of the data, encrypted and without exposing any data, while the system just continues to work with the new data store." Hope this is OK?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/116#issuecomment-722339260, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YPKENMSQIX4DVEWY6DSOKI7XANCNFSM4TH4VTRQ .

[OR13]

@agropper Ii think you are conflating technical clarity with a basic use case, and suggest this feedback belongs in SDS and not here.

[agropper]

@OR13 As read it, this use-case is only about: "continues to work".

1. Alice gives Maria, one thing: a DID.
2. Maria processes that DID in order to configure something about an confidential service that she has chosen and paid for.
3. When Maria changes the confidential service, the Alice's DID "continues to work".

Presumed in this case, Alice is presenting her DID to https://maria.com/heresmydid

1. Alice is authenticated.
2. Alice sees the contents of her basket at the confidential service because her user agent was redirected to wherever Maria chooses.

I think I've seen this flow somewhere before :-). The difference may be that Maria used something from Alice's DID to encrypt the basket before writing it to the confidential service and that Alice's user agent needs to have access to Alice's DID in order to decrypt the basket.

If this is what's we're calling an Encrypted Data Vault, then I'm totally fine with the PR and apologies for wasting your time.

[OR13]

@agropper you are not wasting time :)

I agree with your presumption, I just don't think we need to make it explicit here...

Just to restate it in my own way:

DIDs contain encryption keys which can be useful when interacting with confidential storage systems.

We don't need to say how here... because we are talking about DIDs generally... we do need to say how in SDS WG.

[jandrieu]

@OR13 In fact, it is the goal of the use case to explain, in concrete terms, what value people have and get from DIDs, with minimal recourse to the solution engineering. Not-quite correct statements like "DIDs contain encryption keys which can be useful when interacting with confidential storage systems" both mistate what the actual solution is (DID Documents contain keys, not the DID itself), and ignores the value that an actual user gets from the technology. People don't interact with confidential systems for their own direct benefit. Rather, people use confidential systems for particular use cases like sharing health care records with a new doctor or securely collaborating as part of a joint development partnership.

@agropper The DID that either party gives the other can be configured to "continue to work", because they can always update the service endpoint used for this shopping functionality. HOW that is achieved is in the solution space. The WHY that is useful is what we are capturing here.

The current text fits my understanding of the problem space and value proposition of this use case. I'd like to merge it.

[agropper]

I’ve moved on. The section is ok with me as it is. I just think it’s less than helpful to introduce the EDV or Hub term and then write use-cases to fit. Confidential store is better. Prescription, or “Alice rents a car” is a lot better.

On Fri, Nov 6, 2020 at 11:25 AM Joe Andrieu notifications@github.com wrote:

@OR13 https://github.com/OR13 In fact, it is the goal of the use case to explain, in concrete terms, what value people have and get from DIDs, with minimal recourse to the solution engineering. Not-quite correct statements like "DIDs contain encryption keys which can be useful when interacting with confidential storage systems" both mistate what the actual solution is (DID Documents contain keys, not the DID itself), and ignores the value that an actual user gets from the technology. People don't interact with confidential systems for their own direct benefit. Rather, people use confidential systems for particular use cases like sharing health care records with a new doctor or securely collaborating as part of a joint development partnership.

@agropper https://github.com/agropper The DID that either party gives the other can be configured to "continue to work", because they can always update the service endpoint used for this shopping functionality. HOW that is achieved is in the solution space. The WHY that is useful is what we are capturing here.

The current text fits my understanding of the problem space and value proposition of this use case. I'd like to merge it.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/did-use-cases/pull/116#issuecomment-723170652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJ7MCDE2TX3THM6MHLSOQPPPANCNFSM4TH4VTRQ .