Capabilities-based identity updates

[orthecreedence]

It occurred to me that having having root/publish/policy keys is somewhat rigid. Instead what makes more sense is to do away with this model, and instead use the concept of a set of management keys (distinct from subkeys, which are really more for storage) and capabilities. When an identity is first created, the capabilities would still map to exactly what they are now, however they could be updated in more interesting ways, such as allowing external keys to update various parts of the identity. This would allow an identity to be cryptographically managed by many people, allowing organizations to self-manage identities without owner-gatekeepers.

So instead of a set of purpose-made keys, we would instead have the alpha key and any number of subkeys that can each have various capabilities (or none).

For now, I'm thinking of adding a capability for just about any transaction type with some obvious exceptions (CreateIdentity , SetRoot/Policy/Publish, ExecuteRecovery, etc would not exist).

Care needs to be taken to allow per-resource ownership/management. Maybe a key can only EditSubkey on a subkey that it created (not someone else's). So a key could have the capability DeleteSubkey (can delete any subkey) or DeleteSubkeyOwned (can only delete a subkey created by that key).

What would be really interesting is allowing policy-based capabilities: ie, "this change is valid ONLY if signed by two of these three keys" ie any combination that can be expressed as hat is now a recovery policy (but would likely be renamed to be more general, like "signature policy").

This would also require transactions to be able to have multiple signatures. Effectively all transactions would be modeled like a recovery policy execution. It would also entirely replace the need for the recovery system because one could create a policy that allows the reset of the management keys (which is effectively what the recovery policy is).

One final thing that's swimming in my head: it would be amazing if the policies could be identity-based such that a signature from any management key in that identity is valid. That way, you could say "require a signature from two of these three identities" as opposed to "require a signature from two of these three specific identity/key pairs." The former is essentially what we want: an identity-based signature (without relying on the alpha key presence). The latter is extremely rigid. This would require each signature shipping some kind of proof that it's indeed a subkey of the alpha key, and this entire proof would need to be recorded into the transaction so it could be verified locally. I'm not sure if there's a way to condense this, but it might get unwieldy vewy quickwy if we have to ship the entire DAG for each signature).

---

What's left

This change is well underway. Making huge advances. Here's what needs to happen to finish the implementation:

• Rebuild protocol with admin keys, policies, and 3-stage transaction flow.
• Convert CLI as-is to use new protocol. This is done by introducing a "staging" are for transactions that can be signed multiple times before being applied. If no staging is specified, the transaction is signed with the first matching admin key (or one can be specified via -k/--sign-with) and applied automatically (mimics the old stamp UX). This change is mostly backwards compatible.
• Reorganize how the stamp and claim functions work. Stamps made by the stamper are now able to be saved ot the stamper's identity and are publicly accessible, so the stamp command should list the stamper's public stamps. That said, the stamps on claims need to be able to be listed as well, however these can be listed as a subcommand of claim, like stamp claim stamps <claim_id>.
  • stamp list
  • stamp revoke
  • stamp accept
  • claim stamp list
  • claim stamp view
  • claim stamp delete
• Add some more UX around staging: show "Ready to apply" column when listing, and message "This transaction can now be applied" after stamp stage sign if the transaction satisfies a policy.
• Add interfaces for managing policies Moved to Allow managing policies in CLI #36
• Need to sync staged transactions in private syncing. This allows a group of pepole managing an identity to all get staged transactions ready for signature. Sync metadata in private sync #37

[orthecreedence]

Started working on this, it's a bit crazy. Basically, the entire architecture needs to change. It's all good things, though. I originally had signatures as transaction IDs. Now, it will be the sha512 hash of the body as the transaction ID, and there can be any number of signatures on a transaction. This won't change a lot of the DAG code, but will change the transactions themselves and how they are created/saved. There's now a three-step process to saving a transactions (used to be one):

1. create the transaction and return it
2. get signature(s) on it
3. save it

This can obviously be automated by the interface to a large extent if we have some concept of a "default" key (or maybe we use the least privileged one that can still perform the action). However, it opens the door to things like multisig, which are more and more becoming important to the project (managing group identities/transactions is a big one, which requires multisig).

Just kind of starting to scratch the surface of this. First things first, going to rework the recovery system to be a generalized policy system (should be easy) then have to convert the DAG to use the new create-return-save. Should actually simplify the DAG because it no longer needs to handle signing transactions...that happens somewhere else.

Wish me luck...

[orthecreedence]

Another note: in places we were signing/verifying before (claim, stamp, publish) we now relegate this to the transaction system. All timestamping and signing happens in the transaction itself. This means for things like claims/stamps, we are passing the entire transaction around instead of specific signed containers. This actually simplifies things quite a bit because all signing/verification happens in one place. It also does something else interesting: since making/revoking stamps are now just transactions, they can be saved to the DAG and this acts as a publishing mechanism...instead of stamps floating around in the ether and requiring some sort of external syncing, they can now be published to the public identity of the stamper which allows for very quick verifications of stamps. Note that it's not necessary to save a stamp/revocation to your identity, but if you wanted others to be able to easily verify it it would be worth it. This will close #20 once merged.

[orthecreedence]

I'm happy to announce this has been merged into master. Glorious.