Summary

  • An individual IETF draft proposes an Agent Authorization Center that keeps a user's agent associations and an autonomous-access list. A listed resource party gets automatic approval; an unlisted one prompts the user; a forbidden one is refused.
  • The resulting access token should identify the user, agent and center. A field telling the resource party whether approval was automatic or human is optional. The draft's Security Considerations section is still TBD.

Someone has to put the service on the list. After that, the agent may walk through without knocking. That is the consequential choice in the 27 October Agent Authorization Center proposal, an individual Internet-Draft for agents on a person's own device. It sketches a way to avoid asking the user every time an agent visits a third-party service. The saved policy becomes the decision maker at the next doorway.

The center, called AAC in the draft, would maintain user identity, links from users to agent groups and agents, and personalized autonomous-access policies. An agent first approaches a resource party with a user identifier and the center's identifier. The resource party guides the agent to the AAC, which receives the user, agent and resource-party details. If the party is on the autonomous list, the center approves without a human in that exchange. If it is forbidden, it refuses. If it is on neither list, it asks the user.

The approved path still uses an OAuth authorization code: the AAC returns a code, the resource party exchanges it for a token, and the resource party validates the token before serving the user. The draft says that token should carry identifiers for the user account, agent and AAC. It says the mode—automatic or human—may be included. That makes the mode optional at the exact point where the receiving service would need to know how the grant was made.

An automatic list entry is a useful tool for routine errands. It is also an authority decision that can outlive the moment when the user selected it. The six-page proposal does not specify action-level limits for a listed service, a versioned policy record, an expiry for the entry or a withdrawal sequence. It says access is ultimately served according to the user's entitlements, but a service name on a list does not by itself describe which purchase, disclosure or account change the agent may make. The practical question is who owns that narrower rule and how a receiver can inspect it.

The current draft labels its entire Security Considerations section TBD. Existing OAuth guidance is more specific: RFC 9700 describes security practice for authorization flows, and RFC 7636 defines PKCE protection for authorization codes. The proposal still needs to specify how its agent, center and receiver roles use those protections; it reports no deployment trial.

The Datatracker record lists the document as an individual Informational draft at I-D Exists. Before a center becomes a gatekeeper, a useful test would add a service to the automatic list, authorize one bounded task, change that list entry, and ask the resource party what it can verify from the next token. The answer should separate a valid token from a human decision made for this particular action.