Closed Gozala closed 1 year ago
@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:
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/add
s during exploit window.store
provider used identity/resolve
from delegated capabilities it would bare no relation to the store/add
invocation that caused it.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:
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.
Closing this in favor of #7 which share same general idea
Also can be viewed as formatted document at https://hackmd.io/@gozala/ucan-keypair (comments are disabled as I'd like feedback here instead).