feat: support execution of delegations #199
Conversation
|
@Gozala where is this https://github.com/web3-storage/ucanto/blob/e84c659268d104e24bfc0d0354ef436b865b12ca/packages/core/src/delegation.js#L192 function called now ? This is where the ucan is signed and it does not seems to be called. |
|
@hugomrdias that in adopting this in w3protocol access-api, I noticed the |
|
wait but that does not solve the problem, we still signing in the codecs. |
… and not sign proxyInvocation. using features coming in ucanto 4.2.0 Motivation: * #325 * simplify access-api ucanto proxy using features added to ucanto in storacha/ucanto#199 * previously, the technique used to proxy the invocation was to issue a new invocation (i.e. `proxyInvocation`) in the proxy server, and then send that to the upstream. This had at least two limitations: 1. required the proxy server to be configured with a `options.signer` to sign the `proxyInvocation` 2. for functional use in access-api and proxying upload-api, this proxy `options.signer` also had to be configured pretty much identically to the ucanto verifier with same did on the upstream, including requiring both to have the same private key * now * you don't need an `options.signer` at all! so you definitely don't need one creating signatures with the same private key as the upstream Steps * [x] release ucanto 4.2.0 storacha/ucanto#200 * [x] update this source branch package.json + pnpm locks to upgrade ucanto to 4.2.0 * [x] ensure `tsc` + tests pass here
… and not sign proxyInvocation. using features coming in ucanto 4.2.0 Motivation: * #325 * simplify access-api ucanto proxy using features added to ucanto in storacha/ucanto#199 * previously, the technique used to proxy the invocation was to issue a new invocation (i.e. `proxyInvocation`) in the proxy server, and then send that to the upstream. This had at least two limitations: 1. required the proxy server to be configured with a `options.signer` to sign the `proxyInvocation` 2. for functional use in access-api and proxying upload-api, this proxy `options.signer` also had to be configured pretty much identically to the ucanto verifier with same did on the upstream, including requiring both to have the same private key * now * you don't need an `options.signer` at all! so you definitely don't need one creating signatures with the same private key as the upstream Steps * [x] release ucanto 4.2.0 storacha/ucanto#200 * [x] update this source branch package.json + pnpm locks to upgrade ucanto to 4.2.0 * [x] ensure `tsc` + tests pass here
Fixes #195