At the moment when we define capabilities we have to provide derives function which is used to compare two capabilities of the same type to decide whether one can be derived from the other. It is annoying to have to define those and requires quite a bit of code.

We could simplify this simply by making schemas also provide includes(capability:A, claim:A): boolean function which could compare two values from the same schema making it unnecessary to do it anything at the capability level.

There is also another class of derives however which works across different capability types (which are discriminated by can field). Things are fuzzier here, because it is no longer obvious how one would include the other, not only can fields differ but also a field set may e.g. in our code base we can derive space/info from store/* and upload/* which is to say size, root etc fields won't exist on space/info yet it should be considered included in any of the upload/*.

• Perhaps it's ok, we can iterate over all claim fields, if some field isn't set yet was set in the capability it is clearly violates imposed limitation. If capability contains some fields that aren't even defined in claim that's ok because those are unrelated.
  • This would mean that filed name a would not be able to restrict field name b, but that's probably a reasonable limitation.
  • Perhaps we could also allow implementing custom includes logic on schemas in case where you need more complex comparison logic

Last class of derives deals with amplifications. That one capability may be derived from multiple other capabilities. This is a tricky one as it's unclear how includes could be implemented at all.