Agent authorisation today is a piece of text inside a token. An OAuth scope, a permission string, a claims blob — whatever the format, the pattern is the same: the agent carries an envelope describing everything it is allowed to do, and shows the whole envelope to everyone. The counterparty’s choice is binary — accept the envelope or refuse it — and the counterparty’s knowledge is total: whoever verifies the agent learns the full shape of its mandate, including every part that is none of their business. Selective disclosure solved this problem for identity attributes years ago. The overdue move is to apply it to authorisation itself.
The scope-envelope problem
Picture a purchasing agent authorised by its principal to buy electronics components, in the EU, until quarter-end, up to a defined limit per transaction. With envelope-style scopes, the merchant it approaches learns all of that — budget ceiling, geographic reach, mandate duration, the lot — because the scope arrives as one readable object. That is negotiating leverage handed to a counterparty, a mandate disclosed to a party with no need to know it, and, aggregated across merchants, a behavioural profile of the principal’s operations. The alternative — stripping the scope down until it says nothing — just recreates the opposite failure: an agent whose authority nobody can check.
Both failures come from the same root: the scope is a document, when it needs to be a set of provable claims.
Five axes, provable one at a time
MintID structures an agent’s delegated scope along five axes, fixed at mint time and each provable on its own in zero knowledge:
- Action — what the agent may do: purchase, book, negotiate, sign a request.
- Counterparty — with whom it may transact: a class of relying parties, or specific ones.
- Category — the domain of the transaction, reusing existing merchant-category vocabularies (MCC) rather than inventing a new taxonomy.
- Geography — where the mandate applies, reusing ISO 3166 country and region codes.
- Time and value — until when the mandate runs, and up to what amount.
Because each axis is a separate provable claim, the merchant in the example above asks the only two questions it legitimately has — authorised for this category? under this limit? — and receives two yes/no proofs. It learns nothing about the budget ceiling, the mandate’s duration, its geographic reach, or which other counterparties the agent may deal with. The proof is scoped to the question, exactly as a zero-knowledge age proof reveals “over 18” and not the birthdate. Selective disclosure, applied to authority.
prove the axis · not the mandate
fig. 1 — selective disclosure, applied to authorisation itself
Unspecified axes fail closed
Structured scopes create a subtle trap: what does the absence of an axis mean? In most permission systems, silence means “unlimited” — the API key that was never geo-restricted works everywhere, the token without an expiry lives forever. For high-value requests, MintID inverts the default: axes left unspecified fail closed. A mandate that never mentioned geography does not silently authorise a high-value purchase anywhere on earth; the missing constraint reads as missing authorisation, and the request needs the principal, not the benefit of the doubt. Fail-open scope is how confused deputies are made; fail-closed scope is how they are contained.
Two siblings: custody class and operator context
The same design movement — turn a due-diligence question into an attested, non-correlatable attribute — extends beyond the mandate to two questions regulated counterparties actually ask.
How are this agent’s keys held? The issuer attests the agent’s key-custody arrangement, and the agent proves “custody at or above class X” — hardware-backed, say — without revealing which device, which vendor, or any identifier that could follow the agent around. The answer arrives as issuer policy, never as a consensus rule, and never as a tracking handle.
Who runs this agent? An optional attested operator context distinguishes who operates the agent from which agent it is — as a cohort class by default (“operated by a regulated EU entity”, not a company name), with an exact identifier available only through explicit selective disclosure when both sides want it. Two agents of the same principal remain unlinkable, always — knowing the cohort of one tells you nothing about the other.
What a prudent verifier asks
Put together, the five axes and their two siblings give a relying party a precise etiquette. Ask for the axes the transaction actually turns on — category and value for a purchase; action and time for a booking. Ask for custody class if your regulator asks you. Ask for operator cohort if your risk model needs it. Expect a yes/no proof for each, expect unspecified axes to fail closed above your value threshold, and expect to learn nothing you did not ask for. The agent in front of you proves it is backed by a verified human, inside a mandate that covers exactly this transaction — and its authority, like its identity, discloses on a need-to-know basis. The envelope is gone; the questions remain answerable, one axis at a time.