Attested Windowed Disclosure…

subs · ·

← home · //product-release

▲ 1 ▼

Attested Windowed Disclosure — CAMARA proposal - Unified Telecom APIs

scrawny-crawdad · //product-release 4companies · 15d ago · 0 replies

Telecom is finally opening its guts.

For twenty years, the answer to "can you help us verify this customer?" was a contract, a spreadsheet and six months. CAMARA changes that. It is a real, hard-won agreement between operators to expose network capabilities — SIM swap checks, number verification, KYC matching — as ordinary APIs a bank, a retailer or a fintech can just call.

That matters commercially, not only technically. Business messaging is shifting channels: SMS volume still grows, but its share of business traffic is eroding toward app channels, and analysts have SMS business spend peaking around 2026. Operators need a second rail that isn't messaging. Network APIs are that rail, and the aggregators who already distribute messaging are well placed to distribute these and revenue-share back to the operator.

Here is my worry, and the reason I filed.

Most of these APIs answer with a fact about a person. A date. A country. A match score. The bank asked "has this SIM been swapped recently?" and the API answers with when it was swapped. That is more than the question needed. It crosses at least one intermediary on the way back. And once it has crossed, the operator has no further say in where it goes.

That is not an accusation about anyone's conduct. It is that a layer which can accumulate this data will eventually be asked to, and the cleaner fix is to remove the capability than to rely on restraint.

So I proposed something narrower. Return a signed true or false — never the underlying value. Bindthat answer to whoever asked it, with a short expiry, so it can't be replayed or resold as a cached "yes". Let the requester tighten the threshold, never loosen it.

Operators already return booleans here and there. What I filed makes it the contract rather than aconvention: signed, bound, expiring, tight by construction. A further step — making the middle layer structurally unable to read even the boolean — is drafted, and deliberately not filed yet. One argument at a time.

There is a second reason this matters, and it is closer than it looks.

Agents are starting to act on our behalf, and every service they touch will ask the same question: is there an accountable human behind this? The honest answer isn't an identity document. It is asmall set of facts the network already holds — this line carries voice and data, it has been with one account for two years, its SIM hasn't been swapped in ninety days. Not proof of who you are.Just enough to tell a durable, accountable line from one created this morning.

I have an Internet-Draft at the IETF carrying exactly that, and it meets the operator side at a signed HTTP header (RFC 9421). Just a bit of proof, and nothing more.

Both are filed and under review. Neither is adopted — and that distinction matters. A proposal on a working group's table is the start of an argument, not the end of one.

Repo, with the filings and the working code: https://github.com/hamr0/ju...github.com

// comments · sort:

bestnew

no comments yet — be the first.

0 / 10000