Platform, surface, session, mission, class

[dickhardt]

@christian-posta @mcguinness

Here is how I think these terms related to AAuth:

• platform: where the agent is running. web, mobile, desktop, self-hosted, workload. Self declared by agent at PS to help user understand where the agent is.
• surface: where the user is interacting with the agent. May be on the platform, common in web and mobile platform, but a web and mobile surface may be how the user is interacting with an agent running as on workload platform. Out of scope for AAuth.
• session: out of scope for AAuth
• mission: a context that grants may be given in. When an agent is granted access to a resource in the context of a mission, it does not have access outside of the mission.
• class: a mechanism for an agent to request access to any agent with the same class from the same AP. Once granted, any agent with that class has access to the same grant. If a class is presented in a mission, then any agent with the same class and a resource token with the same mission has access

I worry that for large APs -- the class may be too broad -- there can be thousands of planner class agents across many users -- and the user does not want to do that -- so class may be better suited for APs scoped to an organization.

building on #22

[mcguinness]

this works for me

Sessions are implementation-specific runtime continuity constructs and are intentionally out of scope for AAuth. Missions are governance constructs representing bounded delegated authority. A mission may survive across multiple sessions, devices, runtime migrations, orchestration environments, and delegated subagents. Likewise, a session may contain multiple missions over its lifetime

Platform - Where execution happens
Surface - Where interaction happens
Session - Runtime continuity (out of scope)
Mission - Authority continuity
Class - Interchangeable execution equivalence
Resource Token - Capability scoped by mission/class

I worry that for large APs -- the class may be too broad -- there can be thousands of planner class agents across many users -- and the user does not want to do that -- so class may be better suited for APs scoped to an organization.

Yes. That concern is right.

Class is more any agent that the AP represents as equivalent within this authority domain, for this mission.