search

decentralized-identity / confidential-storage

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

Trust Levels for Content: Plain Text vs. Encrypted, Signed vs. Unsigned, vs. Not Resolvable: taxonomy proposal for EDV content resources #188

Open mwherman2000 opened 3 years ago

mwherman2000 commented 3 years ago

Trust Levels for Content Resources Different categories of content resources have different trust levels depending on where and how they are stored.

Trust Level Description JWT Equivalent
Trust Level 0. Not Resolvable The identified content resource is not resolvable as a content resource in an EDV data vault. All actions, whether successful or unsuccessful, are logged in a secure way. N/A
Trust Level 1. Unsigned Plain Text The identified content resource is resolvable in an EDV data vault as an unsigned plain text resource. All actions, whether successful or unsuccessful, are logged in a secure way. Unsigned JWT
Trust Level 2. Signed Plain Text The identified content resource is resolvable in an EDV data vault as a signed plain text resource. All actions, whether successful or unsuccessful, are logged in a secure way. JWS (Signed JWT)
Trust Level 3. Signed Encrypted The identified content resource is resolvable in an EDV data vault as a signed encrypted resource. All actions, whether successful or unsuccessful, are logged in a secure way. JWE
OR13 commented 3 years ago

The identified content resource is resolvable in an EDV data vault as an unsigned plain text resource. All actions, whether successful or unsuccessful, are logged in a secure way.

this makes no sense... if you expand the word EDV....

The identified content resource is resolvable in an encrypted data vault as an unsigned plain text resource. All actions, whether successful or unsuccessful, are logged in a secure way.

ENCRYPTED data vaults do not store plaintext.

I'm not opposed to apply plaintext trust layers to hubs, but I am entirely against saying "encrypted data vaults" store plaintext.

tahpot commented 3 years ago

I understand the word EDV is "encrypted data vaults", however in reality developers will want the same interface to handle both encrypted and plain text data.

It is possible to encrypt everything and then share a key, facilitated via hubs, however I'm not convinced that's the best strategy as it has other trade offs that should be carefully considered.

My personal preference is that this WG actually focuses on "Personal Data Stores" which incorporates a users data following the trust levels outlined by @mwherman2000. It's okay to then say the first specifications are the underlying protocol and encrypted storage data structures with the other trust levels out of scope.

agropper commented 3 years ago

I think @tahpot is saying the same thing as https://lists.identity.foundation/g/sds-wg/message/82

mwherman2000 commented 3 years ago

@tahpot is referring to the 4 Trust Levels for Content: https://github.com/decentralized-identity/confidential-storage/issues/188 ...not an agent authorization discussion.

OR13 commented 3 years ago

I understand the word EDV is "encrypted data vaults", however in reality developers will want the same interface to handle both encrypted and plain text data.

I am a developer. I don't want "encrypted data vaults" to store plaintext.

I am fine with "hubs" storing plaintext and exposing them over the same / similar interface.

I think we should split hubs and edvs, we seem to be failing to manage seperation of concerns by trying to address both at the same time.

agropper commented 3 years ago

@OR13 The question I keep asking (#165) seems to be: What do you mean by "same / similar interface"?

My proposal is to define "same / similar interface" such that most resource servers (EDV or Hub or Stream or Directory) interface to a single agent (or a single persona, for technical simplicity) of the data subject. That doesn't mean all resource servers have to use the same standard API but it does mean that there are two layers in our SDS discussion: The policy enforcement layer (RS) and the policy decision layer (AS).

OR13 commented 3 years ago

@agropper By same / similar interface, I assume this would work for hubs:

GET {with http-signature} https://hub.example/hub/123/resources?type=Playlists 
=> returns plaintext over http if authorization succeeds AND plaintext was stored in the hub.

Compare this ^ to the currently working:

GET {with http-signature} https://edv.example.edv/edv/789/documents/012 
=> returns ciphertext over http if authorization succeeds AND ciphertext was only thing stored on the edv.
agropper commented 3 years ago

@OR13 Sorry, but I don't understand the difference between the two. Presumably, both have pre-registered a public key or DID that can be used to verify the http-signature. The "123" is presumably the local index into that pre-registered key or DID.

Why do you put /hub before /123? If /123 was first, then the rest of the URL would be a scope of access. I must be missing something fundamental.

OR13 commented 3 years ago

@agropper I updated the IDs... they are all unique now.... there is no assumption of "pregistration". there is only the HTTP Signatures Spec and the ZCAP spec.... neither of which assume pre-registration of the invoker keys... but which require a capability chain to the root resource.

In other words, resources have a root capability associated with them that helps answer the authorization question in a capability system.

Whether the resource is encrypted or plaintext is no relevant to authorization capabilities.

agropper commented 3 years ago

@OR13 I agree that whether the resource is encrypted or not relevant to the authorization capabilities.

The resource server creates a root capability. What happens to this root capability? Is it communicated to some endpoint by some protocol at some time?

OR13 commented 3 years ago

@agropper the root capability is communicated to the resource creator (in that resources are always created with the creator as their controller)... what happen next is up to the resource creator / controller... they can delegate access with attenuation to any subsequent parties, and the resource server only requires a complete chain of delegation that terminates in that root to decide authorization.

agropper commented 3 years ago

@OR13 Sure. So:

How'm I doing?

OR13 commented 3 years ago

@agropper yeah, thats pretty much how it works... when you "share", you are really doing 2 things:

  1. encrypted a symmetric key to a recipient and updating the recipients
  2. delegating a read authorization to the new recipient

for authorization, technically, you only need 2, its just that the recipient would need some way of decrypting what they have access too... we assume 1 is useful for this, but its not the only way....

for plaintext, you definitely would not need 1.

agropper commented 3 years ago

@OR13 Exactly. So, my proposal is that the authorization protocol be the same for EDV and Hubs. That way, the resource creator and resource server would decide as part of 'first contact' whether to register an authorization server (and risk hostile RS) or just grab a root capability (and create extra copies at a cost for both the controller and the RS).

"Registration" would be optional if the RS offers it and the resource creator accepts it. An EDV would be a Hub that does not support registration of a service endpoint. For example, in terms of DID methods, the creator could do first contact with a did:key and just get a root capability in return. Or, the creator could do first contact with a did:ion with a service endpoint to an authorization server.