peer-base
access control approach
Some questions:
What access control primitives are you planning on providing? Do you have any plans on how to implement these? What API do you think should be exposed to DApps?
I've experimented with doing Access Control with peer-crdt registers, but it's impossible to know when you're caught up. If we used something like uPort or Ethereum based for identities, I could see using Ethereum blockchains for for ACL.
For now, I'm using the peer-crdt register that only an admin can append operations to unless another user is added (all operations are signed, including the ones to the ACL). Operations are rejected if:
- The signature can't be validated.
- The operation wasn't authored by someone who was in the ACL.
The other option would be to make write access something given from the identity server, which seems to be how most identity servers work.
I could queue operations that don't pass ACL, and if ACL catches up to show that user can do that action, the operation is re-inserted. That's how I'm handling missing sessions right now.
@fritzy I think that using an eventually consistent data structure for storing ACLs could be a shortcut but, as you say, it's not possible to know whether you've caught up with the "latest", making any node vulnerable to a suite of attacks, as CRDTs allow concurrent edits.
Since there's not causal dependency between document operations and ACL operations (as they will form independent causal trees), one would have to replay the entire document operations when the ACL changes.
An alternative here would be to embed the ACL in the causal tree, where an operation links to the most current ACL node at the time. This would solve having to replay the document operations every time the ACL changes, since we know that, for every document operation being played, we have the correct ACL resolved.
@fritzy thoughts?
This is really good thinking!
We could either a) have a type that includes ACL operations within it or b) refer to the HEAD of an external ACL CRDT from when the operation was performed.
a) is a bit more complicated to implement but b) means that once you've whitelisted an action by a user/identity/session then it's all but impossible to revoke it unless that revokation applies to the past.
I think embedded ACL within the CRDT type is correct way to do this. Brilliant!
This is being discussed here: https://github.com/ipfs/dynamic-data-and-capabilities/issues/25