Make the "real root" of the capability chain the target ocap itself?

[cwebber]

Currently in the spec the first invokeable capability in a capability chain is one which references a target property and which has the capabilityGrant property (soon to be the capabilityDelegation property). An observation made in Veres One, where frequently an entity wants to be able to invoke itself without the extra storage costs of issuing another capability document, is that the target could itself be a capability document.

The way this fits in with the logic and implementation of current ocap systems: currently implementations I have written build up a list of "currently authorized" participants on the chain, and the target is already added to that by necessity, since the target needs to sign off on granting authority to the initial non-target entity that can use the capability. So... if the target is already authorized to grant further capabilities in the chain, why can't the target also be authorized to invoke? At which point, the target should also be able to self-invoke with no additional capability documents.

Probably this "feature" would most commonly be used in blockchain systems and such, since entities in a server-oriented environment probably can self-modify and run its own methods locally. But in a blockchain system built on ocap-ld, other participants on the network need to be able to replay and verify the behavior of all actions taken in the system. So an entity issuing an invocation to run a method against itself makes sense. It doesn't seem that we should have to require another capability document issued to justify that.

[cwebber]

In doing this, we can actually get rid of invocationTarget altogether, because the target is now a parentCapability.