Must every capability document have an associated id?

[cwebber]

We say so in the ocap-ld spec currently, but if the capability document is embedded with the invocation, I don't see why that's true.

The main case it would make things complicated for is if we support revokeability by default as in #9. In that case, seeing whether or not a capability has been revoked would be done by checking the hash of the ocap document, not the id. This might mean having to hash every document at every stage of the chain, which could be a (minor?) performance penalty.

[msporny]

This might mean having to hash every document at every stage of the chain

Don't you have to do this anyway to check/create the digital signatures on each document?

[cwebber]

Oh... that's true!

The main way in which it's tricky possibly is an implementation detail... the ld-proofs capabilityInvocation verification calls ld-proofs verification on the capabilityDelegation proofs, but doesn't currently pass any sort of argument that would allow it to "reuse" that information. However, I guess this could be no problem: there's a space for the proofPurposeOptions, and we could just pass the hash in there as an optimization. So yeah, no problem.