ucan interop with external services

[Gozala]

🪧 HTML View

I have been thinking how to make "sign the deal with wallet" API that would not require selling UCANs to spade team, yet avoid some secure channel between services (current spade approach) to provide some access control. I have captured some of this thinking in https://github.com/web3-storage/specs/pull/67/files

Talking with @vasco-santos earlier today I also realized we need similar thing for "failed deal" reporting, and unless misunderstood Spade is hoping storage providers can report failures directly to us instead of proxying such reports through some secure channel. So basically same challenge here.

I end up formalizing my thoughts around what are the ways ucan enabled system can interop with ucan disabled system and what are the tradeoffs. Would love your comments

[vasco-santos]

@Gozala thanks for putting this together so quickly!

I would not expect that a interop layer with non UCAN entities would have redelegation has a requirement. If it had, there would even be less incentive to build UCAN based system for other parties.

With the above in mind, The PK solution seems quite great. That model seems to work quite nicely for all the use cases I have in mind, while offering all the security aspects (and even accountability)

[vasco-santos]

I think here is more around the UCAN adoption than a tradeoff of this solution? Would not expect a interop system would give full capability of using UCANs, otherwise this would replace the need for "selling" UCANs

[Gozala]

I had been chatting with @gobengo on related thing which inspired another mode of operation that I'd like to incorporate here:

Lets assume there is an actor that simply wants oath like experience, that is public token and secret token. We could support that as follows:

1. Actor generates random seed token on their own.
2. Actor generates keypair form the seed token (we could teach w3 cli this trick)
3. They generate UCAN delegation with desired access level from their space (or account) to the public key derived from the secret token.
4. They POST to the RPC gateway endpoint passing UCAN delegation as JWT bearer token. They pass seed token as a secret token and capability { can, with, nb } as JSON payload .
5. Gateway derives keypair from the seed.
6. Creates an invocation with passed capability and ucan as proof UCAN and signs it with the derived private key handing off invocation to w3up API endpoint.
7. Gateway extracts receipt from from w3up response and passes it back to the actor