Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

space/content/serve/* capability should allow token in the caveats #213

Open
fforbeck opened this issue Dec 6, 2024 · 1 comment
Open
Assignees

Comments

@fforbeck
Copy link
Member

fforbeck commented Dec 6, 2024

We should enable setting an auth token when delegating the space/content/serve/* capability. This would allow us to validate the token included in gateway requests and determine whether to serve the content based on the validation result.

@fforbeck fforbeck self-assigned this Dec 9, 2024
@fforbeck fforbeck changed the title space/content/serve/* capability should allow authToken in the caveats space/content/serve/* capability should allow token in the caveats Dec 9, 2024
@fforbeck
Copy link
Member Author

Proposal from @alanshaw

I'm not sure it's a good idea to set the token on the wildcard capability.

What if a space/content/serve/* delegation is required for the gateway to serve data and record egress at all. That means that it is up to the service to decide the terms for rate limiting, which may be extremely restrictive eventually.

If you (the user) wants to lift those restrictions or manage your own restrictons you'd also delegate a more specific non-wildcard capability (space/content/serve/http) with a token (and eventually other optional restrictions, like CID, or IP address or referer for example).

I think this is preferable, because the user will want to create and revoke multiple access tokens, without removing the ability for the gateway to serve data / record egress in general.

You'd then perhaps manage tokens in the client like:

interface Client {
  // ... existing methods

  // Calls `access/delegate` with `space/content/serve/http`, allowing access with a user defined token and
  // eventually rate limiting or other restrictions set by the user.
  // Options allows the service to authorize to be customized, defaulting to w3s.link.
  authorizeContentServeHTTP(restrictions: { token: string }, options: Options): Promise<Result<Delegation>>

  // Calls `ucan/revoke` for the given delegation.
  // Options allows the service to authorize to be customized, defaulting to w3s.link.
  revokeContentServe(delegation: Link, options: Options): Promise<Result<Unit, DelegationNotFound>>
}

So, the createSpace function would do what it does currently - delegate space/content/serve/* to enable general access and egress accounting, but for managing tokens you'd use the new methods.

On the server you can then have a KV mapping of spaceDID+token: delegation which you can query to determine if token access is allowed for a space.

storacha/w3up#1603 (review)

Whenever we decide to implement the feature to use the token we also need to add the additional functions to the client to authorizeContentServeHTTP and revokeContentServe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant