Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

access-client should use the ucanto validator to select proofs to send with a capability invocation #566

Open
travis opened this issue Mar 17, 2023 · 0 comments

Comments

@travis
Copy link
Member

travis commented Mar 17, 2023

Right now we use a rough heuristic to select which proofs in an access-client Agent's proof store to send along with a particular capability invocation. Roughly, this looks through each of the stored proofs and compares it with the can and with of a passed capability specification. Once it finds a proof that matches the given capability, it stops looking:

https://github.com/web3-storage/w3protocol/blob/main/packages/access-client/src/agent.js#L169

@Gozala pointed out today in our code review that it's possible for a proof store to be "poisoned" with a proof that matches a particular can and with pair but is not actually valid. This would result in a user not being able to perform some action even though they do actually have all the proofs they need.

In the short term, @Gozala suggested we send along all the proofs we have that match a particular capability, rather than just sending the first one we find:

#433 (comment)

In the medium to long term, @Gozala proposed using the ucanto validator to do this filtering directly, which will more accurately identify proofs that can authorize a particular capability execution.

Peeja pushed a commit to storacha/upload-service that referenced this issue Jan 17, 2025
🤖 I have created a release *beep* *boop*
---


##
[6.0.0](storacha/w3ui@vue-keyring-v5.0.1...vue-keyring-v6.0.0)
(2023-11-21)


### ⚠ BREAKING CHANGES

* use w3up-client in keyring
([storacha#581](storacha/w3ui#581))

### Features

* add support for getting an account's plan
([storacha#564](storacha/w3ui#564))
([11023a4](storacha/w3ui@11023a4))
* re-export Service from `react-keyring`
([storacha#577](storacha/w3ui#577))
([308816d](storacha/w3ui@308816d))
* use w3up-client in keyring
([storacha#581](storacha/w3ui#581))
([bd5f341](storacha/w3ui@bd5f341))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Travis Vachon <travis.vachon@protocol.ai>
Peeja pushed a commit to storacha/upload-service that referenced this issue Jan 29, 2025
🤖 I have created a release *beep* *boop*
---


##
[6.0.0](storacha/w3ui@vue-keyring-v5.0.1...vue-keyring-v6.0.0)
(2023-11-21)


### ⚠ BREAKING CHANGES

* use w3up-client in keyring
([storacha#581](storacha/w3ui#581))

### Features

* add support for getting an account's plan
([storacha#564](storacha/w3ui#564))
([9565452](storacha/w3ui@9565452))
* re-export Service from `react-keyring`
([storacha#577](storacha/w3ui#577))
([94e8b96](storacha/w3ui@94e8b96))
* use w3up-client in keyring
([storacha#581](storacha/w3ui#581))
([2edddd9](storacha/w3ui@2edddd9))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Travis Vachon <travis.vachon@protocol.ai>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant