UCAN keymanagment

[Gozala]

Also can be viewed as formatted document at https://hackmd.io/@gozala/ucan-keypair (comments are disabled as I'd like feedback here instead).

[vasco-santos]

Thanks for putting this together @Gozala

Did not have much time yet to think about this, but my initial thoughts would be more towards the Secure supreme key strategy. I would see services having a owner, which would be dotstorage admin

[vasco-santos]

Suggested change

	2. `did:key:zUpload` need to keep delegated UCAN around in order to invoke `access/reslove`.
	2. `did:key:zUpload` needs to keep delegated UCAN around in order to invoke `access/reslove`.

[hugomrdias]

i like the secure supreme key model and it fit well with my idea of having an UCAN worker in front of all the other workers so we dont replicate ucan logic everywhere.

[Gozala]

@mikeal @hugomrdias I have realized that there is a problem with the idea of having a static DID only for the routing purposes. More specifically we have been going under assumption that a hardware "service key" will simply delegate it's capabilities to "service provider" actor who's keys will be rotating frequently. However doing this would prevent "service provider" from deriving capability (from received invocation) and delegating it to a different actor, because invocation audience will be "service key" not the "service provider". This is problematic because "store/*" provider already derives "identity/resolve" from "store/add" in order resolve an account for the did car is added to.

We could go different route and delegate identity/resolve capability to store/* provider from the hardware "service key", but I think that is inferior approach (or workaround rather) because:

1. It gives store a greater capabilities than required. For example attacker could exploit this to get info about all the accounts in the system, which would not be possible if identity/resolve was derived from store/add because those can only be issued by DID owner so at best attacker could gain access to account info for users that perform store/adds during exploit window.
2. Deriving capability captures invocation trace is a UCAN chain itself. In contrast if store provider used identity/resolve from delegated capabilities it would bare no relation to the store/add invocation that caused it.
3. Provisioning all the right capabilities among various actors with constantly changing DIDs sounds like recipe for cascading failures when anything goes out of sync. In contrast deriving capabilities from actual user invocations seem a lot more resilient as no token coordination is required between individual actors.

Unfortunately I don't currently have solution to offer. Pref-light request to resolve provider DID had been offered previously which I suppose will work, but it has problems of it's own:

1. Number of RPC calls double as you need to first resolve DID of the service and only then can call the API (I suppose client could optimistically use last resolved DID until service responds with error about wrong audience and resolve again still it's pretty sad)
2. It also negatively affect overall APIs especially if you consider the fact that currently it is possible to bundle request to various different actors together.

It is also worth considering that if we rotate keys every 24H this would require engaging that hardware "service key" every 24h which in turn would be too frequent for human interaction and if automated it would create another attack surface.

When I wrote this proposal I imagined rotating service provider keys only when they are compromised as opposed to every 24h. Which I expect to be far less frequent and human would already be in the loop anyway.

[Gozala]

Closing this in favor of #7 which share same general idea