Summary

  • Revision 02 of an individual IETF agent-token draft adds optional and unnamed tool arguments. An omitted optional argument takes the tool’s own default, which the authorization checker cannot see.
  • A "*" entry accepts arguments absent from the token’s map, including ones added to the tool later. The credential can stay valid while the interface beneath it grows.

The Permission Slip Has a Blank Line

An agent receives a signed pass for a tool. The pass names the tool and the arguments it may use. Months later the tool gains a new switch. Does the old pass cover it? In Niki Aimable Niyikiza’s revised draft, a single asterisk can make the answer yes. The signature proves who issued the token. It does not ask that issuer whether they meant to approve a parameter invented after issuance.

The 27 October announcement and IETF Datatracker identify an individual Internet-Draft, not an operating service. Its Attenuating Authorization Token, or AAT, lets a holder derive a token with equal or narrower authority offline. An enforcement point checks the signed chain against the root issuer’s key and checks each proposed tool call against the leaf token’s argument map. That is a useful separation of duties. The trouble begins when the map meets a tool whose interface has changed.

Revision 01 treated the argument list as closed: unknown parameters failed, and named parameters could not simply be omitted. The new draft’s acknowledgments credit an independent implementation with finding that this rule left no way to constrain a genuinely optional argument. Revision 02 answers with two devices. A named constraint may carry optional: true, so a call without that argument passes. The reserved "*" key admits arguments the map never named. Its value must be an unrestricted wildcard. An empty constraint map amounts to the same open door.

The Default Is a Decision Someone Else Made

Consider the draft’s file-reading example. A token pins path to one file and bounds optional head and tail counts. If an agent supplies head, the checker can test its value. If the agent omits it, the tool chooses its default. The draft points out the sting: omission of an optional head can let a file-reading tool return the entire file. The authorization checker sees an absent parameter, not the output the tool will choose. An issuer who approves “optional” has effectively approved that default too.

The asterisk poses a different timing problem. It lets a tool accept every unlisted argument, including an argument introduced in a future version. A token issued today may authorize a setting nobody reviewed today. The draft advises issuers not to use "*" with tools that have side effects. It also lets enforcement points reject arguments absent from a tool’s published input schema. Those are choices at the deployment boundary. The format itself does not freeze a tool version into the old token or force an issuer to revisit the grant when the schema changes.

This is where a cryptographic success message becomes a poor governance report. The verifier can establish that the chain is signed, the leaf holds a tool name, and the current call satisfies the map it received. It cannot infer that the principal who signed the root grant considered a later parameter or the tool’s current default. “The token verified” answers an integrity question. “Who approved this behavior?” requires the interface version, the default and the decision that admitted the wildcard.

The proposal is explicit about its own fault line. Its Appendix F says revision 02 makes normative changes that break revision 01 implementations; optional and unnamed arguments are among the additions. The same appendix describes stricter checks elsewhere, while its security section says open-ended arguments trade enforcement for compatibility. A flexible pass saves token reissue when a tool evolves. It also lets interface maintainers change the effective scope of a permission without touching the signature.

Original records