Refactor grants / rights - don't use a ResourceArray

[joepio]

The Document demo invite is becoming slow. It starts impacting the tests. This is because the ResourceArray of write Agents in the document is starting to contain a lot of URLs. Every time we add one item to it, the back-end has to process quite a bit of data. I know I can find some ways to improve this performance, but the architecture is fundamentally unscalable. Keeping Agent references inside Resources will severely limit how many people will get access to one document.

Basically, currently we use node-based rights. We should consider going to edge-based rights.

One solution is to introduce Groups or Roles.

Another solutions is to put the relationship of Resource :write -> User in a seperate Grant resource: Resource <- :forResource Grant :forUser -> User.

This will be quite the refactor! But I think it needs to be done...

Grant Datamodel

• resource (resource): the resource that grants are applied to
• who (resource, Agent): the Agent who receives the rights
• read (bool): allows viewing the data
• write (bool): allows any edits (including deletion) and any children
• append (bool): allows creating children

Thoughts:

• Maybe make the rights an enum instead of a bunch of booleans, as write means that append is always true. Also, does a write of true combined with a read of false make any sense?
• Should we allow multiple Agents in who? If we do, we may get the same problem that we're currently trying to solve.

Editing, querying and viewing Grants

Inspiration for testing scenarios:

• When a Grant is edited, we need to check if the Agent requesting this has the rights to do this.
• We should probably prevent items from being grant-less: that nobody can edit them.
• Asking if someone has rigths to edit or view some resource should be very cheap.

What needs to be changed

• Create the Grant datamodel
• Make sure that Grants can only be created, read and edited by the right Agents.
• Update the share / rights view in Atomic-Data-Browser
• Update the invite flow
• Migrate existing data (or do we keep the old functionality?)

[joepio]

Design session with @Polleps

[joepio]

Let's walk through how a rights query would be resolved using the graph above. We start with an Agent and a Resource - how do we answer the question if some Agent A has a specific right at a specific resource X?

• Find Grants for resource X
• Find all Roles for all of these Grants (this could be very expensive!)
• Find memberships of these grants where Roles is Agent A
• If not found, repeat the process for the parent

This is very computationally expensive! How do we make this a tad easier?

• Find all Memberships of Agent A (query, probably a small amount)
• Get the Roles R for these memberships (property, very cheap to compute)
• Find Grants of Resource X for all the Roles R
• Check the Rights of these Grants (write / read / whatevs)
• Repeat for parents

But I think we can speed this up more:

• Find the Grants for Resource X with right Y (e.g. Write) - (Get property from resource, or maybe TPF query)
  • If there are no grants, go to the parent
  • If there is a public grant, you're done!
• If there is a grant with a role, search if there is a membership for agent A in this grant (TPF query).

This seems to be decently fast on paper. But would it allow users to set rights wihout roles? E.g. John gives Sarah read access? Some solutions:

• We keep the write and read props, but don't use them in group settings, we prefer roles and memberships.
• We allow grants to point to Roles or Agents directly, skipping the membership.

Should links from Resource to Grant be defined in the Grant or in the Resource? If it's in the Resource, we often get slightly better performance - no need to hit the value index. However, this is not a big impact. Also, it becomes easier to reason about write access to the Grant, because it is in the Resource itself. On the other hand, it will be harder to query on Grants or find all Grants for a person.

[joepio]

We should consider using AuthZEN:

• Open spec, gaining popularity rapidly
• Triples based (zanzibar-style), so philosophically compatible with Atomic schema
• Allows attribute based checks read#field:email

Implementations:

• Use the authzen crate. Seems to be designed for apps with more domain-specific logic in mind. Maybe AtomicServer is too generic
• Do it ourselves. Not sure what that means - do we need specific AuthZen endpoints? We'd need to map groups to AtomicServer groups and things like that.