3.5 Operations: classic set of 4 CRUD operations insufficient. Use CARUMDRIGF

[mwherman2000]

In a modern metadata/JSON based content/resource storage system, the classic 4 operations are insufficient. Consider the following set of operations for completeness: operation=”create” operation=”delete” operation=”remove” operation=”replace” operation=”update” operation=”add” operation=”merge” operation=”ignore”

Reference: https://hyperonomy.com/2021/02/12/psn-tn0028-sps2003-xml-import-export-operation-attribute/

Also: operation=”get” operation=”find”

...10 in total: CARUMDRIGF

[OR13]

I would prefer to see each resource type defined, and explicit operations for each resource type defined... for example:

Vault - create / update / delete / query

etc... I don't know what "ignore" is... in the context of the current spec.

At least for Encrypted Data Vaults... the fact that the operation list is small, is considered a feature.

[mwherman2000]

@OR13 A visual model always helps in these discussions. The following is my personal mental model for what I'm starting to call Trusted Content Storage.

For TCS, I think of the 10 operators as the lowest-level EDV Microkernel operators ...in the TCS model, the Layer A Trusted Content Storage Kernel is the lowest-level interoperable layer.

I would prefer to see each resource type defined, and explicit operations for each resource type defined.

In the TCS architecture, these resource specific operations are relegated to Layer B EDV Trusted Content Storage Services.

[mwherman2000]

One notion that complicates the above discussion is the intention to perform all encryption/decryption operations client-side (i.e. generation of the JWEs). This decision point makes it difficult to implement all of the operations at the level of the EDV Microkernel.

[OR13]

One notion that complicates the above discussion is the intention to perform all encryption/decryption operations client-side (i.e. generation of the JWEs). This decision point makes it difficult to implement all of the operations at the level of the EDV Microkernel.

Client side decryption is pretty important for encrypted data vaults.... because the server and network are considered hostile.

If your diagrams exposed EDVs directly to clients, they would be more reflective of current implementations.

I think its a mistake to try and design a higher order service on top of edvs when they are not done... kinda like building a house on a half built foundation.

[agropper]

@OR13 If the server and network are considered hostile, then what is the purpose of an access control protocol? Is it just to limit resource hijack by other hostile parties? What's the difference between encrypted data vaults and IPFS or https://sia.tech ?

[OR13]

@agropper the worth thing a hostile server can do is deny updates, withold cipher text for authorized parties, or hand out ciphertext to unauthorized parties.

If you allow them access to plaintext, they get to do a lot more....

and obviously, a hostile server can completely ignore whatever authorization you wanted enforced... which is why client side encryption is useful.