Limitation with principal alignment

[Gozala]

We would like to setup a our system such that:

1. User agents would delegate UCAN invocations to known Service DID.
2. Submitted UCAN invocations could be picked by arbitrary service provider from the pool, with an assumption that each provider has own DID and no access to Service private key.

For more context see #95

If we step back a bit from the UCAN spec and focus on semantics, above system could be modeled as follows:

1. did:key:zService could delegate all (or subset) of capabilities to its provider(s) e.g.

   {
     iss: 'did:key:zService',
     aud: 'did:key:zWorker1',
     att: [{ with: "my:*", can: "store/* }]
   }
   
   {
     iss: 'did:key:zService',
     aud: 'did:key:zWorker2',
     att: [{ with: "my:*", can: "store/* }]
   }

2. User agent did:key:zAlice could issue store/add service invocation delegated to did:key:zService e.g:

   {
     iss: 'did:key:zAlice',
     aud: 'did:key:zService',
     att: [{ with: "did:key:zAlice", can: "store/add", link: "bag...hash" }]
   }

3. Service provider did:key:zWorker1 should be able to pick above submitted invocation (from the queue) and in combination with delegated { with: "my:*", can: "store/* } capability should be able to redelegate it to yet another actor e.g. did:key:zExecutor.

   If did:key:zWorker1 can do all the store/* things that did:key:zService can and did:key:zService can do { with: "did:key:zAlice", can: "store/add", link: "bag...hash" } that means did:key:zWorker1 can do it too)

However since UCAN spec requires principal alignment did:key:zWorker1 can not use UCAN delegated to did:key:zAlice in it's proofs. We could probably stick it inside fcts instead but that seems like a workaround.

Does this use case sounds reasonable ? And if so should we have something in the spec to support it ? I don't think removing
"principal alignment" is a good idea, but maybe there could be a yet another list of proofs that one could provide to claim ability that other actor was delegated ?