WRITE ONCE, READ ONCE
One-time data is already part of how the internet works
Single-use codes and short-lived access are established patterns in authentication, deployment, and file sharing. These documented examples show the broader idea behind WORO: make a value available for a narrow purpose, then limit how long or how often it can be used.
IDENTITY RECOVERY · OWASP GUIDANCE
Password reset links and recovery codes
Password reset systems commonly send a token or code through a side channel, then use it to authorize one specific account recovery action. OWASP recommends that reset tokens be cryptographically random, sufficiently long, securely stored, single-use, and time-limited. That makes the token a temporary capability with a defined job, rather than a reusable password.
Pattern: issue a restricted token, deliver it to the account holder, accept it once, then invalidate it.
How WORO relates: WORO can carry a value for one retrieval. It does not verify account ownership or perform a password reset; the application receiving the value must enforce those checks and decide what action the value permits. Read OWASP’s reset-token guidance.
DEPLOYMENT · HASHICORP VAULT
Bootstrapping a machine in a CI/CD pipeline
HashiCorp documents a Jenkins workflow where Vault creates a short-lived, single-use wrapping token for an AppRole SecretID. Jenkins unwraps it at runtime, uses the SecretID to authenticate, and then obtains the Vault access its job needs. The wrapper avoids placing the reusable bootstrap credential directly in the pipeline definition.
Pattern: a job receives a temporary exchange token, consumes it once, and uses the value to obtain narrowly scoped access.
How WORO relates: WORO can transport a short-lived value between workflow steps, but it does not wrap values with Vault’s cryptographic controls or enforce recipient identity and permissions. Read HashiCorp’s Jenkins example.
AUTHORIZATION · OAUTH 2.0
Passing authorization between a browser and an application
In OAuth 2.0’s authorization-code flow, an authorization server returns a code through the user’s browser to the client application. The client exchanges that code for an access token. The standard requires authorization codes to be short-lived and single-use, limiting the value of a code that is exposed or replayed.
Pattern: pass a temporary, one-use value through an intermediary, then exchange it for the next step in a process.
How WORO relates: both use a one-time exchange value. WORO redeem tokens are bearer tokens for retrieving stored data; they are not OAuth authorization codes and do not grant access to another service. Read RFC 6749, section 10.5.
TEMPORARY ACCESS · AMAZON S3
Sharing a file with a time-limited link
Amazon S3 presigned URLs let an application grant time-limited access to an object without changing the bucket policy. This is widely useful for uploads and downloads where a person or client needs temporary access. The link remains usable until it expires, so it demonstrates a related pattern with a different limit: time-limited access rather than one-time retrieval.
Pattern: delegate a narrow operation through a temporary bearer link, then let its expiry close access.
How WORO relates: WORO deletes its stored copy on read and permits only one request to claim the item. It does not issue a direct file URL or control access to an external object. Read the S3 presigned URL guide.
What the patterns have in common
They replace open-ended access with a value that has a limited purpose, lifetime, or number of uses. The exact guarantees come from the system that issues and validates the value.
WORO provides middleware for one piece of that design: it stores a value temporarily, deletes it on read, and expires it after 14 days if unredeemed. It records whether a retrieval operation occurred, but that does not identify the person who made the request or prove they received, read, or kept the response. For the API details and security boundaries, read the developer guide and FAQ.