The direct answer
Decide whether a download requires the current user’s authorization or merely possession of a link. Check issuance and redemption separately, bind the permitted object and operation, and describe expiry, revocation and retained copies according to the actual delivery system.
Choose the delivery model before generating a link
An AI workflow finishes a fictional export E-17 and offers a download. The application checked that User A could create it. That issuance check does not answer what happens when A forwards the resulting link, loses access or downloads a copy before the link expires.
There are two different design choices. An authenticated delivery service checks the current requester and object permissions before releasing content. A transferable capability grants access through possession of a valid credential-like link, subject to the issuer's rules. A label saying “for User A” does not by itself bind a bearer capability to A.
This guide uses inert link metadata only. No signed URL, credential, storage API call, file or download was created or tested. All proposed acceptance cases remain unrun.
Use one documented capability system as a reference
Amazon S3 documentation describes presigned URLs as bearer tokens. Creation specifies an object key, HTTP method and expiration interval; access is limited by the creator's permissions. Temporary credentials can end their validity earlier than the requested URL expiry.
The same documentation states that S3 checks expiry when the HTTP request begins. A download started before expiry can continue past it; restarting after a dropped connection following expiry fails. These are S3-specific documented semantics, not observations from this guide or a guarantee about another storage service, proxy or authenticated download implementation.
Record the system actually used before claiming that expiry stops an ongoing transfer, that a link is single-use, or that removing application membership immediately invalidates a previously issued capability. A short lifetime reduces the period for new use; it cannot retrieve bytes already delivered.
Write an inert link-design card
For the synthetic review, E-17 revision V-1 belongs to User A's workspace. The intended operation is downloading that exact export. The example's ten-minute limit is an invented policy choice, not a recommended universal duration.
{
"export_id": "E-17",
"revision": "V-1",
"operation": "GET",
"delivery_mode": "authenticated_service OR bearer_capability",
"intended_recipient_label": "User A",
"requested_expiry": "T0 plus 10 minutes"
}This card is a design record, not a signature or enforceable access grant. Confirm which fields the chosen issuer actually protects. If exact revision binding is required but unavailable, hold that design or use an appropriate immutable object mapping rather than claiming the card enforces it.
OWASP authorization guidance recommends permission checks on every request. For an authenticated service, derive identity from its trusted session and enforce current object access at delivery. Simply checking login before redirecting to a transferable capability does not make the resulting capability user-bound.
Compare recipient, method, object and time decisions
Define expected outcomes before implementing a local recorder. The bearer column assumes the declared capability remains valid under the chosen issuer's policy; it does not assume a login requirement.
| Proposed case | Authenticated-service design | Bearer-capability design |
|---|---|---|
| A requests permitted E-17/V-1 | Release after current authorization | Release only if capability constraints hold |
| Unauthorized B receives A's link | Deny B at delivery | Possession may permit redemption; recipient label is insufficient |
| GET is changed to a write operation | Deny outside the permitted route/action | Reject under the required method binding |
| Target changes from E-17 to E-18 | Recheck the actual requested object | Reject under required object binding |
| A new request starts after effective expiry | Apply the service's current access/lifetime rules | Reject if the issuer's effective expiry has passed |
| A's membership is revoked after issuance | Deny a new delivery after revocation takes effect | Do not infer immediate invalidation; inspect issuer controls |
| Transfer is already underway at expiry | Use documented transfer policy | Use documented issuer semantics; no universal cutoff |
| A already saved a copy | No recall claim | No recall claim |
Method and object rows are requirements to verify in the actual mechanism, not claims that arbitrary metadata enforces them. Also define how revocation coordinates with authorization and delivery: a separate check followed by a later release leaves a race. State the boundary after which a transfer counts as already admitted.
Treat caches and link exposure as separate paths
A cache can serve a previously obtained response without repeating the expected origin decision. Review content responses, redirects and pages carrying the link. Inspect the actual delivery chain rather than assuming a private-looking URL is excluded from a shared cache.
RFC 9111 distinguishes an unqualified private response directive, which forbids shared-cache storage but can allow private-cache storage, from no-store. The RFC also warns that no-store is not a sufficient privacy mechanism. Neither directive establishes that a recipient has deleted a saved copy.
Keep usable capabilities out of ordinary logs, analytics events, screenshots and support packets. Record safe export and decision identifiers instead. If a capability leaks, the response depends on the actual issuer and policy; do not promise a universal revoke button or remove all legitimate users' access without understanding the effect.
Report the boundary a future check would establish
A proposed offline harness could use synthetic users, a clock and a delivery recorder to exercise the matrix without generating a link or moving bytes. Vary expiry, object revision and membership independently. Include a positive case showing that A can obtain the intended export; denial alone is not a useful workflow. This harness has not been run and would not validate storage signatures or live cache behavior.
Boundary's planned request router does not issue these capabilities or enforce a download service. Its eight mock policy checks concern different synthetic decisions. A future delivery claim should name the system, access mode, verified constraints and unresolved transfer or copy paths.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.