Service DID key rotation

[Gozala]

Hey Folks,

In dag.house we've been thinking how to rotate service keys. I've captured some of my thoughts in regards to proposed key custody based solutions but ultimately we failed to come up with a solution that seems right. Before I go into details here is some wants driving us:

• We would like to have long term Service DID who's private key lives in hardware.
• We would like to use hardware keys infrequently, ideally when we release new product or if some service got compromised.
• Service DID is kind of like a supervisor actor.
• We would like actual invocations delegated to Service DID to be handled by Provider DIDs.
• Providers are like worker actors.
• We'd like to rotate Provider DID on regular bases.
• We would like agents/clients to delegate invocations to Service DID but handle those invocations from Provider DID.

However if client delegates invocation to Service DID provider that picks it can no longer delegate some capabilities from it to other services because it will have a different provider DID.

We have also considered use of did:dns or did:web identifiers for Service DID instead. However it introduces additional complexity and indirection while does not provide a great solution.

Is this something you've though about (If so please share) ?

[cdata]

Thanks for sharing your thoughts on this architecture @Gozala . We are faced with some similar design challenges, but don't have a well-formed solution yet. I would be interested to hear more about how Fission manages key rotation for service-level stuff.

After reading the HackMD, I'm left with the thought: are long-lived delegations across a series of micro-services kind of an anti-pattern? It seems like a long-lived delegation is a special case, and that you want to err on the side of re-creating a short-lived delegation for each meaningful action on state. Does that sound right?

However if client delegates invocation to Service DID provider that picks it can no longer delegate some capabilities from it to other services because it will have a different provider DID.

I don't quite follow this. Are you saying that this is a problem when the Service DID has changed, or when the Provider DID was changed?

[expede]

I would be interested to hear more about how Fission manages key rotation for service-level stuff.

At the service-level (delegating to a service), we have very short-lived keys. Today everything we have is very transactional and unscheduled.

We manually resolve the key at TXT _did.runfission.com and then use did:key. You have lots of other options for this, including did:dns, did:web, and DID .well-known. The challenge is that signatures on rotated tokens can get out of date without some form of anchoring, so if you want to do rotation that keeps old signatures valid (you may not want this), you need to use a DID method that supports anchoring.

At Fission, we know that we'll need some more robust system eventually, but we haven't had a need to yet. We have in fact rotated the service key previously, and it was fine.

After reading the HackMD, I'm left with the thought: are long-lived delegations across a series of micro-services kind of an anti-pattern?

I think it depends on your use case. If you want a service to run lots of actions on your behalf, it may make sense to delegate to them. In web 2.0, we delegate a LOT of rights to services to act on our behalf, and I'm sure that many of those use cases will continue to exist. However, whenever possible, you should follow the principle of least authority, and give the narrowest possible permissions for the narrowest possible time.

[expede]

Sorry, I noted some jargon: "anchoring". This is writing somewhere that a key was valid from time X until time Y, and then was rotated to some new key. You can then match a UCAN's delegation time bounds against that rotation time to see if it was valid when the UCAN was issued. Anchoring this was can be done on a blockchain, or in the key rotation — e.g. by including a pointer to the old doc plus a timestamp, or a list of retired keys and when they were retired. This is baked into a bunch of DID methods directly, though obviously did:key wouldn't support this because it has no concept of rotation.

[alanhkarp]

Are you folks familiar with Sam Smith's Keri for dealing with key rotation?

[gobengo]

Alan, yes, at a very high level and via skims, hearsay, and twice hearing Sam talk about it. Are you recommending it beyond indicating it’s existence?

…

Sent from my iPhone

On Aug 26, 2022, at 3:04 PM, Alan Karp ***@***.***> wrote:  Are you folks familiar with Sam Smith's Keri for dealing with key rotation? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[alanhkarp]

Good. Every time I hear "key rotation," I want to make sure people have at least considered Keri. I'm not familiar enough with the key rotation problem in UCAN to know if Keri is the right solution, but I think it's worth a look.

[bmann]

@alanhkarp yes, thanks for sharing. I have looked at Keri before but generally we need to look a bit deeper. This issue is specifically for services/servers with DIDs, which I don't think Keri really envisions.

The meta challenge here (not for this issue) is broadly having a "bundle of DIDs" (from devices, etc.) that represent an account.