Design note. What exists today: Triage makes the decision and composerID publishes its decision reference into configured downstream systems. What this article describes: a capability or engineering principle we are considering as composerID develops. It is not a claim that this functionality is currently available in production.
If composerID eventually accepts publishing requests directly from other platforms, it needs to know three things about every request: who is calling, what they are allowed to do, and how long that permission should last. Everything in an authentication model exists to answer one of those three questions.
Who is calling
An organisation that integrates would hold two things: an identifier and a secret, issued once, kept safe. When its software wants to talk to composer, it presents both and receives a temporary pass in exchange. The secret stays in one place; only the temporary pass travels on everyday requests.
What they are allowed to do
The temporary pass carries a list of named permissions, called scopes. A reporting integration could hold a pass that reads and never writes. A publishing service could hold one that publishes and nothing else. If a pass leaks, what it can do is bounded by its list, not by everything the organisation could do.
How long the permission lasts
The pass expires, on the order of an hour. Software asks for a new one when the old one runs out, which takes a moment and needs no human. The payoff is that a pass leaked into a log file or a screen share is useless by the afternoon.
The standard behind this
None of the above is our invention. It is the shape of OAuth 2.0 client credentials, a widely implemented standard that every mainstream programming language already has libraries for. Our proposed production model is OAuth 2.0 client credentials with scoped, hour-long tokens, precisely because it is boring: an integrating engineer would recognise the whole flow from the first paragraph of the documentation.
Why not just API keys
An API key, a single long-lived secret sent on every request, is simpler, and many products stop there. It is also permanent, all-powerful and awkward to replace without downtime. A key is a fine way to make a first exploratory call, and our reference sandbox issues personal keys for exactly that. For an organisation’s production integration, the thing that travels on every request should be short-lived and narrow, and the long-lived secret should stay at home minting passes.
What exists today
Our reference sandbox implements this whole model, so the design can be exercised and criticised: it issues tokens, enforces scopes and expires passes on schedule. It is a reference implementation for evaluation, not a production service. A production version would need further engineering, from how secrets are stored to how tokens are verified at scale, and those steps are on the build order rather than behind us. This article is a design note for exactly that reason.
Written with Claude. This post was drafted with Claude, Anthropic’s AI model, working from the composerID repository: the registry, the schemas, the reference sandbox and the vendor documentation it cites. Edited and published by the composerID team.