Actions/methods as a special kind of caveat

[cwebber]

To prevent ambient authority, the toplevel capability document should specify a list of actions (read: the types valid for the invocation document) which are acceptable. Later documents in the chain may specify actions from the original set to further restrict the number of acceptable actions.

This change based on conversations with @alanhkarp on best practices within certificate-style ocap systems, and I believe is something @msporny and @dlongley wanted to do anyway to reduce ambient authority.

[cwebber]

I am putting this in the implementation, using the term allowedAction.

[dlongley]

Sounds good, as long as it isn't a hard requirement. The first time a capability is "delegated" ("granted") it makes a lot of sense to do that. But we have use cases where a DID Document is a capability itself with all defaults for "invoker" (itself), "invocationTarget" (itself) ... and hasn't been delegated via a proof.