Multiple Keys per Agent - Sessions

[joepio]

Relates to #49

Currently, Agents have excactly one publicKey. This has a couple of problems:

• If a user loses their private key, or it is compromised, there is no (standardized) way to communicate what happened to previous keys.
• Some forms of authentication, such as device-bound keys, or session keys, are not possible with one-key-per-agent designs.

Let's discuss what it would mean to support multiple. There may be various approaches possible.

Make Keys Resources instead of Atoms

Agents can create a Key resource, which has:

• The public key (base64 serialized Ed25519)
• An expiration date (optional)

The keys will no longer be stored as an Atom in the Agent, but as separate resources. However, the agent could in fact have a resourceArray of active Key resources which it links to. We could use this relationship to check which keys can be used.

I notice I'm kind of struggling with setting a two-way relationship here. On the one hand, I'd like to see the Agent that created a Key, looking at the Key. On the other hand, I'd like to prevent having the information about which keys are from the Agent set on only one single thing, not on multiple properties with different directions.

Have a usedKeys property on an Agent

• Agents will have one publicKey, an many usedKeys. Only the currently active publicKey should be used.
• When a public key is added, we add the previously used one to usedKeys.
• If agents need mutliple keys (e.g. one per device)... well, bad luck

Agent has ActiveKeys and DeprecatedKeys

• Both are arrays of strings containing base64 public keys
• ActiveKeys should be considered valid as of now, deprecatedkeys should not be accepted. They can, however be used to validate previous commits, as they indicate previoussly valid keys.