Terms as first-class
The owner does not just decide — she states what she requires, and the agent signs it.
Alice's authority does not ask what the agent will accept. It proffers her terms: the purpose, the scope, how long, and what is forbidden — as a document at a URL that keeps working.
- Alice's authority does not ask what the agent will accept. It proffers her terms: the purpose, the scope, how long, and what is forbidden — as a document at a URL that keeps working.
- The agent echoes the template back, signed with the key it will later use to prove possession of the grant. One key, two jobs — so the party that committed is the party that calls.
- The echo is checked field by field. A valid signature over weaker terms is exactly what an adversarial agent would send, so a dropped prohibition or a stretched expiry ends the negotiation.
- On grant, her authority returns a receipt that embeds the agent's signed agreement and counter-signs it. Both sides now hold the same dually-signed record, and neither can produce a version the other cannot check.
In most authorization systems a decision is a boolean that leaves no trace of what it was a decision about. The caller asked, the system said yes, and the log records that access was granted at a timestamp.
This profile makes the owner's requirements an artifact. The authorization server dictates terms; the agent signs them; both sides keep the receipt.
What terms contain
Four things, machine-readable:
- Purpose — what this access is for, in the owner's words
- Scope — which resources and which operations
- Expiry — how long, in seconds
- Prohibitions — what the agent is agreeing not to do
The prohibitions are the part people underestimate. A grant says what is allowed; only terms can say what the agent has undertaken not to do with it — reuse it for a different order, retain the data, act beyond the approved parameters. Nothing enforces a prohibition at the wire level, which is exactly why it needs to be recorded and signed rather than assumed.
These are her fields, on her surface. The tier above governs a specific resource, so the same four values are what every agent asking for her holdings must echo back and sign.
Where the pattern comes from
The shape follows IEEE 7012 — the MyTerms pattern. An individual proffers machine-readable terms from a roster she controls; a counterparty agrees; both sides keep a record. The important inversion is who authors them. Not the service, offering something to accept or leave. The individual, stating what she requires.
The lab keeps every version of every terms document dereferenceable at a stable URI for the life of the authorization server, because an agreement that points at terms nobody can retrieve is not checkable later.
Why the agent signs
A signature makes three things true that consent checkboxes do not.
It is attributable. The agreement is signed by the agent's key, and that key is the same one the grant binds to. The party that agreed and the party that acts are provably the same.
It is specific. The signature covers the exact terms document, by hash. Not "the terms as of some date" — these terms, this version.
It is mutual. The authorization server counter-signs a receipt. Afterwards, each side holds a record neither can quietly revise.
What this buys the owner
She can answer, later, questions that most systems cannot: what did this agent undertake, when, and against which version of my terms. The ledger is a projection over exactly those events.
It also changes what a breach looks like. If an agent exceeds what it agreed, there is a signed statement of what it agreed — which is the difference between an incident and an argument.
The honest limit
Signing terms does not enforce them. An agent that promises not to retain data can retain data, and no protocol prevents that. What the signature gives you is a durable, attributable record that the promise was made, which is the precondition for every remedy that follows — technical, contractual or legal.
The profile is careful about this distinction, and so should anything you build on it be.