Draft ORKS spec hands revocation of a leaked API key to whoever finds it

A scanner finds a key in a public commit, and the next hours go to working out who issued it and who at that company reads the security inbox ^[1]. SecurityWeek puts that lag at hours to days, against an attack window of minutes ^[1].

OAuth solved the same shape of problem in 2013. RFC 7009 gave it a revocation endpoint that a client discovers through a well-known configuration URL and calls programmatically ^[2]. Plain API keys, which SecurityWeek identifies as the credential type that leaks most often, never got an equivalent ^[3]. GitHub proved the string-format half of the idea on its own tokens, where fixed prefixes made scanning tractable and embedded checksums removed false positives ^[5].

What runs in production today is GitHub's Secret Scanning Partner Program: providers register their key patterns, GitHub scans public commits, and revocation fires over a webhook ^[9]. It works, and it is centralized and closed, with providers admitted by invitation ^[9]. That is why the current generation of open-source scanners share one roadmap item, automatic revocation through provider APIs, and one obstacle, which is that each of them has to build every provider integration by hand ^[10].

Unauthenticated revocation trades one risk for another, and the proposal says so. If possession is authority, whoever finds a leaked key can break the production integration that uses it with a single curl ^[11]. The counterweight is borrowed from Toyota's andon cord, which any worker can pull without halting the factory on the spot, and which stops the line only if nobody resolves the problem inside a window ^[15]. Here the window is a timer, 24 hours by default and advertised in the discovery file, after which the key dies unless the owner expedites the kill or cancels it from an authenticated dashboard rather than an email link ^[12]. Set against the minutes an attacker needs, a 24-hour ceiling is slow containment and fast wind-down: the design buys griefing resistance by giving up immediate certainty for same-day certainty ^[1].

The gap is adoption. ORKS is a draft spec in a GitHub repository written by the person proposing it ^[13], and no issuer, scanner project, or standards body is named as committed to shipping it ^[2]. The statistic carrying the argument, that most leaked secrets are still active years later while bots scrape public repositories continuously, arrives without a dataset behind it ^[14]. Each component has shipped somewhere already, in OAuth, in security.txt, in GitHub's own token format. None of them has shipped together, and no first issuer has published.