Symmetric/private key encryption not suited for decentralised access control

Created by: absoludity

This came up while looking at #408 (closed) and #450 (closed) (both related to secure links) and working to understand the purpose of the encryptionMethod property. To summarise, the spec wants decentralised access control for non-public data and specifies using (symmetric) key encryption for implementing that decentralised access control and passing a key out-of-band. I don't think this will be useful (more below). The spec also talks about using role-based access control which would (I think) remove the need to publish encrypted data in the first place. This looks like a saner way forward (though would require running some infrastructure, with support for people to use common platforms of their choice).

Details

Having looked through the documentation, the encryptionMethod property appears to only have one option when specified: AES . AFAICT, if specified as "AES", it indicates that the target of the link is encrypted with symmetric key cryptography and so can be decrypted by anyone with the key.

The DCC docs say the following about encryptionMethod:

encryptionMethod defines whether the target is encrypted and, if so, using which algorithm. THis provides a privacy/confidentiality mechanism to protect more sensitive content. The decryption key is assumed to be passed out of bounds.

And the Decentralised Access Control page has an overview that reads well and speaks of access control, but then the conceptual model says:

The conceptual model for decentralised access control is relatively simple. All non-public credentials are encrypted with a unique key for each credential. Access to encrypted data then boils down to the mechanism by which authorised parties acquire decryption keys from a data holder that may not know the requestor.

I am not a security expert, but I don't think using symmetric key cryptography for access control to decentralised data is going to be very useful, as there is no possibility to re-encrypt the data in the case of a leak (ie. no way to do key revocation). At that point it is public data.

The credential id is public and everyone can refer to it in graphs etc., but the resource itself (the credential), if not public, would need to be protected by access control other than symmetric key cryptography, so that it can be better managed. In fact, the role-based access control mentioned on the same page would seem to remove the need for any encryption, given that an anonymous access token could be used instead of a symmetric key.

For example, rather than sending a symmetric key with a product as a way of distributing the key to the purchaser so that they can access the data (which, once that key is leaked, makes the already published encrypted data essentially public data), it would be much more manageable (I'd think? Again, no-expert-disclaimer) to send an access token with the product which enables the purchaser to access the private data (ie. it's not published anywhere other that at the location specified by its ID, and there it is protected). Yes, the purchaser could copy the data and make it public, but that's traceable and quite different to publishing the data yourself with a symmetric encryption key (which I wouldn't do personally, if it was private data). The page talks about using DID access control for role-based access, so I'm not sure why there's a need to publish the encrypted data in the first place - people can refer to the ID, and only those with access should be able to view the credential associated with the ID.