Client should authorize Gateway to space/content/serve Spaces by default

[hannahhoward]

The Uploader says, "I generally want people to access the files I upload, so now that the Gateway will require authorization, I need to authorize it.

Acceptance Criteria

1. If a user creates a space, then the gateway must be authorized to serve the content of this space. So a new delegation space/content/serve/* must be stored in the Delegations Store (Freeway can learn about space/content/serve/* delegations #160), so the Gateway can find it, validate, and authorize the request.
2. If the content is served, an egress event must be stored in the egress-traffic-events store in DynamoDB each time the content is requested. Without the proper space/content/serve/* delegation the egress event is not generated.

Main Tasks

• Update the w3up-client to create the new delegation when a new space is created #194
  • approved: feat!: content serve authorization w3up#1590
• Update the w3up-client to send a UCAN request to save the delegation in Cloudflare #193
  • approved: feat!: content serve authorization w3up#1590

Open Questions

• What about new uploads to existing Spaces?

[fforbeck]

Gateway Content Serve Authorization Flow

flowchart TD
    subgraph Client Side
        A[User] -->|Creates Space & Authorizes Gateway| B[w3up-client]
    end
    
    subgraph Cloudflare Workers
        C[Access/Delegate Endpoint]
        F[Freeway Worker]
    end
    
    subgraph KV Storage
        D[Delegations Store]
    end

    B -->|UCAN: access/delegate| C
    C -->|Validates Space & Proof Chain| E[Validate Space Exists & Capability]
    E -->|Stores Valid Delegation| D
    F -->|Retrieves Delegation| D[Delegations Store]

Loading

Explanation

1. User Interaction: The user interacts with the w3up-client to create a space and authorize the gateway to serve content.

2. UCAN Invocation: The w3up-client invokes the access/delegate UCAN handler, providing the delegation details ({ space, proofs }). The request is sent to the Cloudflare Access/Delegate Endpoint.

3. Validation Steps:

   • The endpoint checks whether the space referenced in the delegation has been provisioned.
   • It validates that the delegation matches the expected capability (space/content/serve/*).
   • It ensures the proof chain is valid.

4. Relevance Check: Only delegations associated with a provisioned space are accepted to prevent unnecessary resource usage and mitigate the risk of DoS attacks.

5. Storing Delegation: After successful validation, the delegation is stored in the KV Store (Delegations Store) for further use.

6. Freeway Worker Retrieval: The Freeway Worker retrieves the validated delegations from the KV Store to serve content for authorized spaces.

Key Considerations

• Mitigating DoS Attacks: By verifying that the space is provisioned before accepting the delegation, we can reduce the risk of abuse from unauthorized or irrelevant requests.
• Efficiency: This additional validation ensures only relevant delegations are processed and stored, minimizing resource waste.
• Implementation: Adding a check against the space provisioning status in the Access/Delegate Endpoint can be done efficiently by querying the space registry or relevant provisioning database. I will probably tackle that in a second iteration.