Feedback on UCAN Secure Key Management Presentation

Working Groups Webnative Filecoin Integration
1

From Jonathan Schwartz @j_schwartzz, Filecoin slack permalink.

Feedback on video of initial R&D presentation:

I had a chance to watch the talk this weekend. Wasn’t working with too much time, so I watched the sped up version, I’m really sorry if I missed any important details! Throughout this message, if you see anything and think “he must have not understood X part”, feel free to correct me.

First thing to note - loved the intro and the way you talk about your principles - these are some complex talking points that are articulated in a digestible way (at least for me!). In the coming months we’ll be launching a project that I think has a lot of potential points of collab with Fission, we share similar mindsets. Excited to tell you more about that in the near future

From a technical perspective, in order to give any valuable feedback, I’d need to dive in way deeper and look through the architecture specs, rewatch certain parts of the video, dig into UCAN (a lot) more, try and hack it…etc. I’m so swamped with other work right now, i probably won’t have time to do this for a couple months at least. However, I bulleted some high level questions, comments, suggestions that were going through my head while watching (in thread):

  • I wasn’t 100% sure of the final “recommendation” - my takeaway was the ideal private key management setup for a user is a multisig wallet, where each signer is a 2of2 BLS - where each BLS signer is the user and another is a “cosigner” service. If i understood it correctly, I think this is a really interesting architecture design, the bullets below prefaced with [architecture] relate to… this architecture!

  • [architecture][for devs] - it seems secure (again, would need to spend more time getting into the weeds), but does it end up being cumbersome for the developer? Building just 1 multisig interaction, where the number of multisig signers >1, ends up being a pretty tough state to manage for average developers - can this be made easy, in (for example) just one API call (I should be looking at your docs right now to see if this is supported already)

  • [architecture][for end users] - lots of signatures leads to bad UX? I used to work on an app that asked the user to sign a lot of consent messages to conduct various actions. On one hand, it was very decentralized - i owned my keys, my permissions, and the like - on the other hand, it was annoying, slow, and a process full of frictions. With so many places requiring signatures, do normal end users end up with a poor UX?

  • [architecture] - is more decentralization always better? This is a contentious point, and one that (I’m assuming) could be debated for a while, but is more decentralization (measured by things like key custodianship, signatures required) necessarily better? Do users always want to be in charge of their keys? What do you trade off when making this assumption? What do you trade off without it? (fwiw, i think the answer here is “it depends on the use case”)

  • [filecoin] - I’m sure you’ve already gotten to this point in your journey, and probably know a lot more than I do by now, but I don’t think just being able to sign messages from within the browser means you can execute and maintain storage deals from the browser. I saw you were talking with the Powergate folks, so I’ll leave it to them to talk about storage deal brokerages, making deals directly with miners, other avail options…etc. I’d also recommend talking to @eshon about what’s going on in lotus world to make this aspect easier - she knows all

  • [possible future integration] - you could look at making libraries for more secure PKCE - there isn’t any “standard” library i’ve seen for this, and your architecture is very well positioned for decentralized oauth using PKCE (this is another thing we’re working on, would be happy to chat about more in the future once things slow down). Normal oauth 2.0 usually relies on the client having secured a “secret”, which means clients must have backends, which means clients must deploy and maintain a backend, which means longer time and more money to getting your app shipped. Can we create new oauth protocols with PKCE and fission?

2 Likes
2

Absolutely, yup! Also worth noting that while you absolutely can originate a UCAN on the server, they were really conceived of as way to leave the user in control, which is a pretty severe break from current OAuth flows.

A thing we thing about a lot. We’ve landed on “progressive decentralization”, and everything needs to feel familiar to a typical “web 2” user, ideally making their experience smoother (as well as more secure and sovereign).

3

Right, in general, and for how the Filecoin multisig is implemented, getting an n-of-m confirmation in a multisig actor is a highly stateful, and tricky to orchestrate (a first message proposes the transaction, subsequent messages need to confirm the message. We propose here to work with a Multisig where the required number of signers is 1 (of m), and in this case the initial message proposing, is also immediately executed. If a user would change requirement >1, this would be out of scope of the current middleware.

For the 2-of-2 BLS signature aggregation, we propose that the cosigner functions as a relayer to a Lotus endpoint (MpoolPush to submit a signed message to send FIL to the mempool). That way the flow is linear, and almost stateless:

  1. user needs to get update on cached nonce
  2. form message and sign with user held SecrKey1
  3. API user calls to cosigner service with UCAN token to request cosignature
  4. cosigner signs same message with SecrKey2, aggregates both signatures
  5. cosigner calls on Lotus endpoint with JWT to MpoolPush message
  6. in MultiSig actor proposal executes in the same call (requirement = 1)

great point! we actively want to reduce the times a user is asked for permission and instead ask a clear permission for a contextual constraint for a session. Eg. “Can this app sign transactions for a maximum of 0.1 FIL in the next 10 minutes?” We can constrain this using UCANs, which can delegate and attentuate permissions, which are checked last by the cosigner before it signs off. This way the user story isn’t interrupted for every signature, instead the upfront overall constraints are enforced.

Actually, I believe “no”. More precisely, users (myself included) don’t want to actively manage their keys. That is just an overhead, software should manage keys. Users can manage the authorization though. By using 2-2 BLS we replace a private key with an OCAP authorization scheme (the private key that signs for the aggregated signature isn’t known by any party).

2 Likes
4

sweet, thanks for the reference, good to know. Yes, we updated our intention to implement V0.2 Intent to Implement Webnative Filecoin Implementation. We saw that it doesn’t make sense / nor is possible to “fully manage” storage deals from the users browser session. So instead we use the non-custodial wallet to pay FIL to a party (eg. Fission) for keeping hot storage and go and arrange cold storage deals on Filecoin.