services providers need to take delegations they can use

[Gozala]

There is some background story here storacha/specs#7, but general idea is that we want to have a chain of command

flowchart TB
   root>"📜 did:web:web3.storage"]-->| rotate on compromise  |manager("🔑 did:key:zManager")

manager-->|rotate regularly|access("🤖 did:key:zAccessWorker")
manager-->|rotate regularly|upload("🤖 did:key:zUploadWorker")

Loading

Where top key is in the safe deposit box, manager key(s) are only used to delegate to individual workers. This implies that our services will only have worker keys, however they may need to act on behalf of the root meaning they should be able to issue following capability to the user when they authenticate

{ with: 'did:web:web3.storage', can: './update' }

In other words services need a to be given authority to do so in form of delegation chain which they can utilize

{
  iss: "did:key:zManager",
  aud: "did:key:zAccessWorker",
  att: [{ with: 'did:web:web3.storage', can: "*" }],
  prf: [{
    iss: 'did:web:web3.storage',
    aud: 'did:key:zManager',
    with: 'did:web:web3.storage',
    att: [{ with: "did:web:web3.storage", can: "*" }],
  }]
}

So they can utilize it when performing delegations like those. These will also become necessary for invocation receipts

[Gozala]

/cc @hugomrdias

[Gozala]

In the short term we can just put root keys into workers, but we should plan to do something along the lines of above down the line.

[Gozala]

I've updated example such that only root DID is did:web and rest are did:key that is because use of did:web in other positions implies more lookups or coordination for no obvious benefit, which is why I think in those cases we should use did:key's instead. That's not to say we don't publish them in DID document, we probably should. Even then we should probably refer to them in a form that does not requires resolution which is did:key