{ "compartment_id": "section-5-1", "number": "Section 5.1", "title_local": "The standards were public and dated: Valve builds against them every day", "title_english": "The standards were public and dated: Valve builds against them every day", "source_url": "https://phishdestroy.io/steam_dossier/#integration-paradox-title", "source_document": "index.html", "content": { "html": "
\n
\nSection 5.1 — The standards were not unpublished\n

Valve builds against these rules every day. It did not build to them here.

\n

Steam ships on the App Store and Google Play, sells through the major card processors, and consumes third-party APIs like any other large platform. Each of those relationships carries a published, dated security requirement that Valve must satisfy to keep operating. Set the dates of those requirements against the dates on which Steam's own Web API acquired the same protections. Nothing below is a private standard, an internal memo or a trade secret: every row is a public document with a publication date.

\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Published external security requirements, with their dates, set against the date the Steam Web API acquired the equivalent control
The published standard, and the date it took effectThe Steam Web API on the same question
Scoped authorisationOAuth 2.0 — RFC 6749, . Section 3.3 defines scope so a client receives only the access it asks for. It has been the default of every major platform API since.Granular scopes arrived on .Before that a single Steam Web API key carried full read and write over the account's trades regardless of why it was issued. Thirteen years and three months after the specification that defines the control.
A key is not an authorisationGoogle's own Cloud documentation: A standard API key doesn't authenticate a principal, and for APIs that create or manage resources, don't use authorization keys in production.The Steam Web API key was exactly that.A bearer string, issued to an account, sufficient on its own to read the inventory, cancel a pending trade and send a new one. No principal was authenticated at the point of use.
Multi-factor authentication on privileged accessPCI DSS 3.2, requirement 8.3 — mandatory from for all non-console administrative and all remote access to the cardholder data environment. Apple then required two-factor authentication of every Developer Program account holder from : developers with the Account Holder role in a developer program will need to enable two-factor authentication to sign in.A second factor was required to create an API key from .Until then a stolen session cookie was enough, with no prompt on the account holder's phone and no notification afterwards. Four years and nine months after Apple made Valve itself use a second factor merely to sign in to a developer portal.
Credential lifecycle and revocationTwitch requires of every third-party application: Your app must validate the OAuth token when it starts and on an hourly basis thereafter, and states that it audits for applications that do not. Its legacy v5 API was retired outright on on a published schedule.No published key-lifecycle record.The 2023 change protected the creation endpoint. No Valve statement located with it addresses keys already registered, and no changelog accompanied the change at all. Whether keys created before it were invalidated cannot be established from public data — which is the question a data subject would need answered to know whether a key created on their account years earlier is still live.
\n
\n
\n
\n
\nArchitectural Benchmark // Token Architecture\n

GitHub Fine-Grained Scopes vs Valve Steam Web API

\n

Valve developers manage open-source software on GitHub daily using granular least-privilege tokens. Compare that with the monolithic key issued to 130M Steam players.

\n
\n\n
\n
\n\n
\n
\n
\n
\n\nGitHub Fine-Grained Token\n
\nUsed by Valve on GitHub\n
\n

Fine-grained token with scoped isolation and mandatory lifecycle enforcement.

\n
\n
\nRepository Access:\nSelected Repos only (1 repo)\n
\n
\nIssue Permissions:\nRead-only [✓]\n
\n
\nCode & Secrets:\nNo access [✕]\n
\n
\nExpiration:\n30 Days (Mandatory TTL)\n
\n
\nAudit Logging:\nIP, User-Agent & Timestamp\n
\n
\n
\n
\nSecurity Posture: Least-privilege token limits damage to a single read-only resource.\n
\n
\n\n
\n
\n
\n
\n!\nValve Steam Web API Key\n
\nIssued to 130M Users\n
\n

Single 32-character master string carrying all-or-nothing trade and inventory authority.

\n
\n
\nAccount Access:\nFULL ACCOUNT (Monolithic)\n
\n
\nTrade Management:\nRead, Cancel, Decline [!]\n
\n
\nGranular Scopes:\nNONE (Arrived 2026, 13y late)\n
\n
\nExpiration:\nNEVER (Valid indefinitely)\n
\n
\nAudit Logging:\nNONE (Zero IP history for user)\n
\n
\n
\n
\nVulnerability: Stolen key allows silent interception of all outgoing trade offers.\n
\n
\n
\n
\n
\nThe standard applied in one direction\n

Suppose a vendor Valve depends on — a cloud provider, a payment processor, a CDN — left a credential endpoint without a second factor, and months later Valve's own corporate data left through a key minted at that endpoint. Would Valve accept that the fault lay with whoever clicked the link? The archived refusals preserved in this dossier answer the mirror-image question for the user: the position taken is that the account holder created the key and bears the loss. The same architecture is described as the vendor's failure in one direction and the user's responsibility in the other. Which it is, is not a technical question, and it is not one this investigation can settle — it is what a court or a supervisory authority decides.

\n
\n
\nIllustration, not evidence — the standard read back the other way\n\n

None of these is offered as a finding about any named company. They are the same design decisions, moved to a setting where the supervisory response is well documented — which is the comparison a regulator is being asked to make.

\n
\n

What the record establishes: the controls absent from the Steam Web API were public, dated and, in several cases, conditions Valve had to satisfy to keep shipping its own products. The interval between each standard and the equivalent Steam change is measurable and is set out above. What it does not establish is why. No Valve statement of reasons for any of these intervals has been located, and none is assumed here; that record exists inside Valve and has not been published.

\n

Sources, each a public document: OAuth 2.0 — RFC 6749, October 2012 ↗ · Google Cloud — API keys documentation ↗ · PCI DSS 3.2 requirement 8.3 — PCI SSC resource guide ↗ · Apple — Upcoming Two-Factor Authentication Requirement for Account Holders, 20 February 2019 ↗ archived 2025-05-06 ↗ · Twitch — token validation requirement ↗ and the v5 shutdown notice ↗ archived 2025-01-27 ↗. Steam's own dates are those in the update record in this section; the 2023 and 2026 entries are the ones Valve shipped without a changelog. Retrieved 2026-09-22.

\n
" }, "original_content_sha256": "494d3acfc3a0b3d03355278324d0e9ad28128e4dd8cce7ba3585be5945235223", "author_pseudonym": "Agent Lucia", "schema": "phishdestroy.macro-fact.v1", "language": "en", "aggregator": "PhishDestroy", "exports": { "pdf": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_1_agent_lucia.pdf", "json": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_1_agent_lucia.json", "signature": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_1_agent_lucia.json.asc" }, "integrity": { "signed_object": "steam_dossier_section_5_1_agent_lucia.json", "signature_file": "steam_dossier_section_5_1_agent_lucia.json.asc", "signing_key_fingerprint": "129FC7F39C40C69D2EF3C329BFCF9E8DD295EE01", "scope": "Exact JSON bytes, including macro-fact author and corresponding PDF SHA-256. PhishDestroy is the integrity signer; original evidence attribution is unchanged." }, "pdf": { "filename": "steam_dossier_section_5_1_agent_lucia.pdf", "sha256": "56d98c4a471164225d073d3c03a7bea7c989ecd83780d50e543cecce58a00297", "pages": 5 } }