When we talk about Zero-Knowledge Multi-Device Identity System several times we've talked about improvements we could make to simplify our Capability blob, and the whole "device linking" process (as we used to call it).

Current Approach

Currently the way device linking works is quite hard to reason about (although it gives lots of flexibility).

The main idea of the current flow is that each key is basically an independent account. Until it wants to get merged with some other account.

You'd create a Web Crypto key in the browser, and sign a Profile blob with it. With an autogenerated name or a user-provided one.

Because this key is not extractable and is only stored in the browser, you'd want to link this key with the one you have in your app.

After a complex back-and-forth communication established between the app and the browser, you'd end up with 3 different blobs:

A Profile blob signed by the "session" key (the one in the browser), claiming that it's an alias of some other parent key (the one in your app). This Profile blob would be invalid, unless there's a Capability blob described below.

A Capability blob where the app key is signer, and web key is delegate. The designated role is called AGENT (nothing to do with AI agents, we did it before 😅). This Capability gives the web key the permission to act on behalf of the app key.

A Capability blob in the other direction — web key is signer, app key is delegate. The idea is that web key is ephemeral and may get lost, but we want someone to be able to edit its data just in case, so we delegate a Capability to the parent key you have in your app. I think we never actually used it, but it's an escape hatch.

We made it this way, because we used to allow users to comment immediately, right where they're at. But now we are moving away from this — we want users to create their persistent identity first, and then link their session key. And to simplify the access to their persistent identity we're implementing this Vault service (because most people don't have the app, yet).

Concerns

The AGENT role. In the era of AI agents, the Capability role AGENT can be misleading. In our case we meant a key acting on behalf of some other key, not something acting autonomously, or at least not necessarily.

Complexity. Because we require users to have a persistent identity now, it seems like we can simplify a lot the whole key delegation flow. No need to pretend we are merging separate accounts, we could just be explicit about the fact that one key is a "child" of another key.

Caveats. Current our AGENT Capabilities have no caveats — no restrictions as to what they are allowed to do. They also have no TTL.

Ideas

Here's a list of ideas we've been discussing so far, in no particular order (numbered just for easier referencing):

Change the name of the Capability role to SESSION. Treat the old AGENT role the same. No particular benefit other than stopping proliferation of the word we think doesn't fit.

Add caveats to the Capability. E.g. the Account ID of the site where the session key is created.

This limits the Capability in its power. But may pose challenges when e.g. commenting on third-party embeds on documents you were granted rights to. May need additional Capabilities for those.

We could also just limit the action allowed by the session key — e.g. only allow to write comments for now, until we figure out web document editing.

Add expiration time to Capabilities. Means that user will need to re-delegate when expires. Probably not a lot of practical benefit from this, because revocation is hard anyway, because if an attacker gets the key, they can backdate anything.

Reference parent account ID on comments signed by session keys. Currently we don't do that — we only rely on the Profile "redirect" (the alias field). I'm doing this now. I think it's a must at this point.

Simplify the whole process. E.g. don't create a Profile with a redirect for the session key, nor the capability from session to parent. Maybe include some proof in the first capability that would be enough to verify that both the session key and the account key wanted to become one identity.