A team wants an in-house HTTP authentication scheme sent as 'Authorization: AcmeSig <signature>' with a matching WWW-Authenticate challenge. What would you weigh before approving that, and what does the IANA HTTP Authentication Scheme Registry have to do with it?
answer
- scheme names = IANA global namespace
- Bearer already means opaque credential
- real gap = request signing / proof of possession
- spec: grammar, canonicalisation, replay, rotation
- Authorization gets redirect and cache protections
basics
~20 sScheme names are a shared namespace registered with IANA, so an unregistered name risks collision and no generic client will understand it. Prefer a registered scheme, most often Bearer. Invent one only for a real gap such as request signing, then define its grammar, error signalling and registration path.
solid answer
~50 sThe framework is deliberately extensible, so a custom scheme is legal — but it is a **namespace and ecosystem decision**, not a coding one. Weigh: (1) **Is there a gap?** Most "custom" needs are `Bearer` plus a token format. Genuine gaps are request signing over method, path and body digest (AWS SigV4 and HTTP Message Signatures exist for this), mutual auth, or channel binding. (2) **Namespace.** `auth-scheme` names live in the IANA HTTP Authentication Scheme Registry; picking an unregistered name means possible collision with a future standard and zero interoperability — no browser, proxy or SDK will implement it. (3) **Tooling cost.** Every client, load test, SDK, and debugging tool must be taught it; browsers cannot prompt for it, so it is API-only. (4) **Cryptographic risk.** Home-grown signing schemes fail on canonicalisation, replay windows, clock skew and key rotation. If you still proceed: use a clearly vendor-scoped name, specify the exact grammar (token68 or auth-params), define the challenge and error params, and pin it to TLS.
go deeper
Know that the scheme name after Authorization is not arbitrary vocabulary — names like Basic and Bearer are registered and mean specific things.
Explain that the framework is extensible but names come from the IANA registry, and that Bearer already covers opaque credentials.
Argue the tooling and security costs: no browser support, every gateway and SDK must learn it, and home-grown signing fails on canonicalisation and replay.
Frame it as a namespace and ecosystem decision with an exit path — adopt a standard such as HTTP Message Signatures, register anything you mint, and record the tradeoff explicitly.
## What extensibility actually buys you RFC 9110 makes the authentication framework scheme-agnostic on purpose: `WWW-Authenticate` and `Authorization` carry a **scheme name** plus scheme-defined data, so new schemes can appear without changing HTTP itself. That is why `Bearer` (RFC 6750) could be added years after `Basic` and `Digest` with no protocol revision. ## The registry is the shared namespace Scheme names are a **flat global namespace** administered by IANA as the *HTTP Authentication Scheme Registry* (holding `Basic`, `Digest`, `Bearer`, `Negotiate`, `Mutual`, `SCRAM-SHA-256`, `HOBA`, `vapid` and others). The registry does two things: it prevents two parties from meaning different things by the same token, and it makes a challenge **self-describing** — any client that meets an unknown name can look it up rather than guess. Registration follows the usual IETF specification-required process; it is not a rubber stamp, and that friction is deliberate. Using an unregistered token like `AcmeSig` is not a wire violation, but you are squatting: if a future RFC registers that name, your deployment and the standard collide, and no generic tooling will ever recognise yours. ## Ask whether the gap is real Most proposals for a custom scheme collapse into "we have an opaque credential", which is exactly `Bearer`. `Bearer` says nothing about token format — JWT, opaque handle, PASETO — so choosing it costs nothing and buys universal client support, standard `error="invalid_token"` / `error="insufficient_scope"` challenge params, and off-the-shelf gateway integration. Real gaps do exist: - **Request signing** — you want the credential bound to method, target URI and a body digest so a captured header cannot be replayed against a different request. That is what AWS SigV4-style schemes and HTTP Message Signatures (RFC 9421) address. - **Mutual authentication** — the client wants proof of the server too, beyond TLS. - **Channel or key binding** — proof of possession of a private key rather than presentation of a bearer secret. If your requirement is one of these, prefer an existing standard over a new scheme name; RFC 9421 in particular lets you sign requests with `Signature` / `Signature-Input` fields without minting a scheme at all. ## What a custom scheme obliges you to specify If you truly proceed, write it down as a spec, not a wiki page: 1. **Grammar** — token68 (`AcmeSig aGVsbG8=`) *or* auth-params (`AcmeSig keyId="k1", sig="..."`), never both; remember quoted strings may contain commas and that params are case-insensitive by name. 2. **The challenge** — what `WWW-Authenticate: AcmeSig ...` carries: `realm`, any nonce or algorithm hints, and error parameters so clients can distinguish expired from malformed from insufficient. 3. **Canonicalisation** — byte-exact rules for what is signed, since intermediaries reorder and normalise headers and re-encode paths. Nearly every home-grown signing bug lives here. 4. **Replay and clocks** — nonce or timestamp window, allowed skew, and what a server does with a replay. 5. **Key management** — identifiers, rotation, revocation, algorithm agility. 6. **Transport** — TLS required; a signature does not protect the response or confidentiality. ## The costs people forget - **Browsers cannot participate.** A custom scheme yields no native prompt and no credential caching, so it is an API-only mechanism; anything user-facing needs a separate flow. - **Every hop must be taught it.** API gateways, WAFs, service meshes, load-test rigs, SDKs in five languages, and the support engineer with curl. "Just add a header" becomes an org-wide integration project. - **Auditing and review.** Standard schemes come with public cryptanalysis; yours comes with your team's afternoon. - **Header hygiene.** `Authorization` is stripped by well-behaved clients on cross-origin redirects and excluded from shared caches; a credential smuggled into a *different* custom header (`X-Acme-Signature`) loses those protections. Keeping credentials in `Authorization` is a security property, not a formality. ## The judgement call The defensible position at architecture review: use `Bearer` unless you need cryptographic binding of the credential to the request; if you do, adopt HTTP Message Signatures or an established signing scheme; mint a new `auth-scheme` name only if you intend to register it and to own the client-side ecosystem work. "We invented it, it lives in one internal service, and only our SDK speaks it" is survivable but should be a recorded decision with an exit path, not an accident.
- Why not just put the credential in a custom header such as X-Acme-Signature instead of Authorization?Authorization has protocol-level protections that a custom field does not: clients drop it on cross-origin redirects, shared caches must not reuse responses to requests carrying it, and logging and redaction tooling already treats it as a secret. A bespoke header inherits none of that and is more likely to be logged, cached against, or forwarded to a third party.
- When is Bearer genuinely not enough?When possession of the header alone must not be sufficient to make an arbitrary request. Bearer tokens are replayable by anyone who captures one, so if you need the credential bound to the method, path and body, or proof of possession of a private key, you need request signing such as RFC 9421 HTTP Message Signatures or a SigV4-style scheme.
saying these in an interview costs you the question
- Treating the scheme name as purely local, ignoring that it is a globally registered token
- Reaching for a custom scheme when the requirement is just 'an opaque token', which is Bearer
- Designing a signing scheme without defining canonicalisation, replay windows or key rotation
- Assuming a browser can be made to prompt for a custom scheme like it does for Basic
- Moving the credential out of Authorization into a custom header and calling it equivalent