MIP: 3
Title: Delegated keys
Author: Jason Chavannes <jason@memo.cash>
Status: Draft
Created: 2018-09-13
Associate multiple keys in a hierarchy with a single identity. The original parent key will be the main address associated with the identity.
Having only a single key associated with an identity has a couple of limitations. First, your identity can only be associated with a single service. Second, you must trust that service to practice good security with your key and cannot use security measures like cold storage if your identity is being used regularly.
Having a hierarchy of keys enables linking an identity across multiple services. The primary keys at the top of the tree can be secured in cold storage. Intermediate keys can be used similar to being your own certificate authority and using intermediate certs. Can use schemes similar to OAuth to easily sign-in and link identity between services.
Can also be extended in the future to limit capabilities of child keys. For instance you might want a service to be able to post on your behalf but not change your name.
Another action that could be added are aliases. Even though posts would be associated with a single identity, you would know which services they came through.
| Action | Prefix | Values |
|---|---|---|
| Link request (MLR) | 0x6d20 | parent_address(20), message(196) |
| Link accept (MLA) | 0x6d21 | request_tx_hash(32), message(149) |
| Link revoke (MCR) | 0x6d22 | accept_tx_hash(32), message(184) |
id_tx_hashis the canonical main identifier for the identity- The tx_hash of the first MLR of the identity
- For first link accept, use request tx hash
- For subsequent links, use original
id_tx_hash
All addresses in a hierarchy are part of a single identity with its own reputation. It is possible to merge multiple identities by making the parent of one a child of the other.
Once a child is revoked all of its children are revoked as well, the entire branch is cut off. If addresses in that branch are still used they will be part of a new identity.
The hierarchy is still maintained within the cut-off branch. Activity in the branch will be grouped with the new identity, unlinked to any previous identities. The branch can be re-attached to the original identity, to a new identity, or kept as its own.
-
You have an existing identity using a service provider like memo (Key A)
A -
You signup for a new service and choose to use Memo auth
-
The site creates a new key (Key B) and issues an MLR transaction
A B -
You are redirected to Memo to accept the MLR (using an MLA)
-
The child acceptance transaction is sent and redirected back to new service
A / B -
Accounts are now linked, also no login required for new service
Fine to use Key B with site for awhile before linking to main Key A identity if desired.
Assume existing hierarchy of Keys A, B, and C:
A
/
B
/
C
To replace Key B, create and link Keys D and E and start using instead of Keys B and C.
A
/ \
B D
/ /
C E
Once all uses of Key B have been updated to use Key D (and C to E), revoke Key B.
A
/
D
/
E
In the case where you want to replace the master key it's a similar process. Assume existing hierarchy of Keys A, B, and C:
A
/
B
/
C
To replace Key A, create and link Keys D, E, and F and start using instead of Keys A, B, and C.
D
/ \
A E
/ /
B F
/
C
Once all uses of Key A have been updated to use Key D (and B to E, and C to F), revoke Key A.
D
/
E
/
F
Even though no longer a valid key, the main identifier for the identity will remain the same.
If a child key is compromised, can revoke it to start ignoring actions. Actions would still exist with the child key, but they will be disassociated with your identity.
Planned