A vendor consortium, not a government body
OASIS (the Organization for the Advancement of Structured Information Standards) is a nonprofit consortium founded in the early 1990s, funded and driven by its member organizations — companies, government agencies, and individuals — rather than by national delegations (ISO/IEC's model) or a single government agency (NIST's model). Standards are developed inside member-run Technical Committees (TCs), each scoped to one specification area, and ratified as an "OASIS Standard" once the TC reaches consensus.
This structure is what let OASIS take on a role neither NIST nor the IETF was positioned to play: hosting the long-term, multi-vendor governance of specifications that started as one company's format but needed to become everyone's shared interface.
What OASIS has actually standardized
Three specifications from OASIS show up directly in this catalog.
OASIS standards this site actually uses
Ratified as an OASIS Standard in 2005 — the XML-based federated-identity assertion format covered in the federated identity use case.
The hardware-token API covered in depth in its own use case — see the next section for how OASIS came to own it.
A network protocol letting an application's key-management requests work identically across HSMs and KMS products from different vendors — see "Go deeper" below.
Why a consortium ended up stewarding a vendor's format
PKCS#11's origin is exactly what the name suggests — one of the numbered PKCS specifications originally published by RSA Laboratories, a private company. A single vendor owning the de facto standard API for hardware security tokens was a real long-term risk: any direction RSA Labs took the spec, every other HSM and smart card vendor had to simply accept. In the early 2010s, RSA transferred stewardship of PKCS to OASIS, where the PKCS 11 Technical Committee now governs it by open, multi-vendor consensus instead of one company's roadmap — the same neutral-governance argument that makes the IETF's open process valuable, applied retroactively to a spec that didn't start out that way.
This is worth knowing specifically because it explains something that otherwise looks like an inconsistency: why a "PKCS" standard — a name tied to RSA Laboratories — is cited today as an OASIS specification with its own OASIS-hosted version history.
Practice
PKCS#11 was originally published by which organization, before OASIS took over its stewardship?
Go deeperKMIP: the standard behind "why can my KMS talk to that HSM"⌄
PKCS#11 solves one problem: how a single application talks to a single token or HSM it's directly connected to. KMIP solves a different, network-level problem: how a key-management system, its clients, and multiple HSMs or KMS products from different vendors can all speak one protocol to create, locate, and manage the lifecycle of keys across an entire enterprise's infrastructure — not just perform one cryptographic operation on one token. A large organization running HSMs from more than one vendor, needing them to all report into a central key-management layer, is the situation KMIP specifically exists for.