Skip to content

Commit f348273

Browse files
wilwadewilwade
committed
Initial Passkey control key design doc
1 parent 85c4e96 commit f348273

File tree

2 files changed

+167
-0
lines changed

2 files changed

+167
-0
lines changed

‎designdocs/README.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,8 @@ To create a new design document, Please see the [Design Doc README](https://gith
2222
- [PR](https://github.com/frequency-chain/frequency/pull/900)
2323
- [Graph Sdk](./graph_sdk.md)
2424
- [PR](https://github.com/frequency-chain/frequency/pull/1159)
25+
- [Passkey Control Keys](./passkey_control_keys.md)
26+
- [PR](https://github.com/frequency-chain/frequency/pull/)
2527

2628
## Basic Data Model
2729

‎designdocs/passkey_control_keys.md

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
# Passkey Proxy and MSA Control Key Support Design Doc
2+
3+
## Context and Scope
4+
5+
The goal of this design doc is to expand the possibilities for self-custody of MSAs via the new technology of Passkeys.
6+
The [Passkey Proxy](./passkey_p256.md) pallet already enables token holding by Passkey holders.
7+
Expanding this capability to the signature methods of the MSA and other pallets would open Passkeys as a method that could be used outside of the token environment.
8+
9+
### Why Is This Needed?
10+
11+
#### Expansion of Self-Custody Options for MSAs
12+
13+
Self-custody is difficult to use for MSAs due to the nature of the signature system.
14+
While this expands the possibilities for non-token holding users, it decreases the self-custody.
15+
Currently on Frequency there are only a handful of self-custody MSAs.
16+
Making self-custody easier would expand the user control of MSAs that are part of Frequency's core mission.
17+
18+
## Proposal
19+
20+
Frequency should provide a system for Passkeys to be control keys on MSAs.
21+
22+
To be updated with the specific chosen details.
23+
24+
## Options
25+
26+
Note: Options are not presented in any specific order.
27+
28+
- [Passkey Direct](#passkey_direct)
29+
- [Passkey Proxy Direct](#passkey_proxy_direct)
30+
- [Wrapped Signatures](#wrapped_signatures)
31+
- [Specific Extrinsics](#specific_extrinsics)
32+
- [Signature Pre-registration](#signature_prereg)
33+
- [Control Key Two-Step](#two_step)
34+
- [MSA Proxy](#msa_proxy)
35+
36+
### **Passkey Direct** <a id='passkey_direct'></a>
37+
38+
MSAs could have direct support for the p256 addresses and signatures.
39+
This would require either a mixed signature type or a separate set of extrinsics, not just for the MSA pallet, but other pallets that rely on signatures as well (Handles, Stateful Storage).
40+
41+
#### Pros
42+
- Potentially easy, and direct Passkey signature control
43+
44+
#### Cons
45+
- These direct Passkeys have some of the same issues around portability and locked website control (discussed in the [Passkey Proxy Design Doc](./passkey_p256.md)) that would undermine the goal of more self-custody and portability.
46+
47+
### **Passkey Proxy Direct** <a id='passkey_proxy_direct'></a>
48+
49+
All signature required methods should also support direct token action.
50+
The user could just use the Passkey Proxy to act.
51+
52+
This would require the ability for Control Keys to use the updated address format.
53+
54+
#### Pros
55+
- Passkey -> Address code already exists in the proxy
56+
57+
#### Cons
58+
- The goal is that users are able to use these without tokens as well
59+
60+
### **Wrapped Signatures** <a id='wrapped_signatures'></a>
61+
62+
Create new or extend `MultiSignature` to support a signature with the components like the Passkey Proxy uses.
63+
64+
This expanded `MultiSignature` would have the following components:
65+
66+
- Passkey Public Key
67+
- Passkey Signature
68+
- Passkey Authenticator Data
69+
- Passkey Client Data Json
70+
- Account Ownership Proof Signature
71+
72+
The result of the verification of the signature would need to be the Account Owner address.
73+
74+
#### Pros
75+
- In theory this could be used anywhere a `MultiSignature` is required. Easy use in all the existing setups across pallets.
76+
77+
#### Cons
78+
- Extending `MultiSignature` is not an easy task and can have a lot of unforeseen side-effects.
79+
80+
### **Specific Extrinsics** <a id='specific_extrinsics'></a>
81+
82+
Just make a new set of extrinsics for each use case that can handle the Passkey data set.
83+
84+
#### Pros
85+
- Straightforward
86+
87+
#### Cons
88+
- Lots of new extrinsics
89+
- Lots of potential bugs and issues with changes in the future
90+
91+
### **Signature Pre-registration** <a id='signature_prereg'></a>
92+
93+
Add a way for the signature to be registered with the Passkey Proxy pallet before use.
94+
In this way, the other side need only handle the lookup on the Passkey Proxy.
95+
96+
#### Pros
97+
- None
98+
99+
#### Cons
100+
- This is a bad idea. It is in here as it might spur other ideas.
101+
- The user would need tokens to register the initial signature.
102+
- Even if it were possible via capacity, this fails to clean up and has expansive costs to maintain.
103+
- Still requires new extrinsics or some other way to submit the data with the action.
104+
105+
### **Control Key Two-Step** <a id='two_step'></a>
106+
107+
Add (or completely switch to) a two-step control key add process.
108+
A dual signature system requires the coordination outside of the chain.
109+
Instead, the flow could be an "authorize" and "accept" system.
110+
111+
The current Control Key authorizes a new Control Key, but it does not become a Control Key until the newly authorized key submits an acceptance.
112+
Since each key is acting independently, the action is from each key.
113+
The signatures are validated outside of the MSA pallet.
114+
115+
#### Pros
116+
- Simpler coordination of adding a new control key (of any kind).
117+
- Might be more powerful if paired with an MSA Proxy concept.
118+
119+
#### Cons
120+
- Doesn't solve the need for a Passkey-based Control Key to submit a signature for things like changing handles or other signature required MSA actions.
121+
- Would likely require making the acceptance/rejection of an authorization either free (charging at the authorize step) or Capacity based.
122+
- Free or Capacity transactions are not currently possible with Passkey Proxy.
123+
124+
### **MSA Proxy** <a id='msa_proxy'></a>
125+
126+
This would need its own design doc, but the core idea is that instead of having various places an MSA control key signature is required, there would be one place to call that then proxies the call with the correct authority.
127+
This would reduce the complexity of the extrinsics and could handle multiple authorization from delegation to direct.
128+
It could also support Token, Free, and Capacity transactions.
129+
130+
#### Pros
131+
- Simplifies how someone is authorized to be an MSA.
132+
- Easier to add other permissions and authorization methods.
133+
- Simpler security for MSA Control Key actions
134+
135+
#### Cons
136+
- Would likely still need to be combined with another option here to fully support adding control keys in this way. (See Control Key Two-Step)
137+
- A large set of extrinsics would be deprecated.
138+
- Should be reviewed in parallel with other design doc proposals around MSA permissions and delegations.
139+
- Increases the cost of all signature required extrinsics as currently each is optimized for the best possible replay prevention which might not be as efficient with an MSA Proxy.
140+
141+
## Non-goals
142+
143+
Note: Some of these may become required, or fall out of requirements depending on the implementation option selected.
144+
145+
- Permission system for Control Keys for MSAs (separate design doc)
146+
- Support for Ethereum Address Control Keys
147+
- Design of an MSA Proxy and MSA Origin system to have a clear origin for the user acting
148+
149+
## Benefits and Risk
150+
151+
### Benefit: User Options
152+
153+
Users will have a greater options when choosing where to place their trust for their root of control of the MSA.
154+
155+
### Risk: Complexity
156+
157+
Options are good, but increase the complexity on both the Frequency side as well as the Providers who need to be able to interact with such signatures.
158+
159+
### Risk: P256 is Expensive
160+
161+
As P256 is not yet a native curve, and instead the signature verification is executed in WASM, the verification cost is much higher than `secp256k1`, `sr25519`, or `ed25519` which all have native host functions.
162+
163+
## Alternatives and Rationale
164+
165+
To be completed after the option is selected.

0 commit comments

Comments
 (0)