decentralized-identity / confidential-storage

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

Add bank safe deposit box use case #65

Closed mxshea closed 4 years ago

mxshea commented 4 years ago

Splitting out the Bank safe deposit Use Case from the original issue: https://github.com/decentralized-identity/secure-data-store/issues/41#issuecomment-635511903

Text from the original issue:

Notice that authorization is about logical resources, not raw storage... we could go super fine grained and implement a permission model for every word in a block of memory... but thats imo, an internal implementation concern...

The authorization interface that users care about (that is reflected in the spec in abstract form), is logically equivalent to a bank vault.

You register with a bank for a safe deposit box.

The bank authorizes you, walks you into the vault and pulls down your safe deposit box... they then leave you alone with it.

You use your key to open the box, and inside are all your documents...

The bank vault is the edv server... just like bank of america and chase have separate vaults... Transmute and Digital Bazaar have separate EDV servers.

The safe deposit box is the "edv vault", its the thing that holds your documents... unlike the safe deposit example.. the bank knows how many documents you have. Now imagine that each safe deposit box that you have only has 1 one document.

When you grant your child access to the box, the bank will pull it down for them, but they still need a key to open it.

The bank employee is the authorization layer... they operate on the logical layer (safe deposit boxes)... they don't operate on data inside a document... they don't tell you where you can and cannot write on your will or birth certificate... and likewise, i argue that the spec should not apply authorization below the logical storage layer.

EvanTedesco commented 4 years ago

Have we considered the "User has passed away and next of kin inherits safe deposit box but no key was previously assigned". In the above it seems implicit that the next of kin would have had to receive a key prior to the User passing in order to access the contents of the vault even if the bank authorizes the next of kin.

In the physical world, a death certificate and proof of kinship is provided to the bank. The next of kin is escorted into the vault by the bank manager, the lock is drilled, and the contents of the box are inventoried for tax purposes prior to the next of kin receiving the contents.

In this case, the bank has no right to read the contents of a personal journal contained in the box, but can certainly have "read access" if there are gold bars, bundles of cash, or other valuables.

In the EDV sense It almost feels like there could be 3 level of access.
1) Information that my next of kin should get access to(E.G. my personal journal/photos ect.) 2) Information that my next of kin gets access to and (potentially) the EDV provider has some level of access to(E.G. my digital currency/assets). 3) Information that dies with me(E.G. My browser history... hopefully... )

Not sure if this is part of this use case or a separate use case entirely but something worth considering in the layers discussion.

OR13 commented 4 years ago

We have a use case for this now, what is remaining / can we close this issue?

mxshea commented 4 years ago

I believe we can close this.