Scope

A task token’s scope is the intersection of three sets:

effective = user_scopes ∩ agent.allowed_scopes ∩ requested_scopes

The three sets

Set	Comes from	Decided by
user_scopes	The subject token from your identity provider	What the human may do
allowed_scopes	The agent’s registration	What the agent may do
requested_scopes	The scope parameter on the exchange	What the agent asks for

An agent should ask only for what the current job needs.

Example: the user holds jira:read, jira:comment, jira:admin and confluence:read. The agent is registered for jira:read, jira:comment and confluence:read. The request asks for jira:read, jira:comment and jira:admin. The token carries jira:read jira:comment: jira:admin is not allowed for the agent, and nobody asked for confluence:read.

An empty intersection is an error

If no scope is left, the exchange fails with invalid_scope. Subact ID never issues a token with no scope.

Scope only narrows

• At issue, the intersection above.
• At refresh, the requested scope must be within what the task already holds, and the agent’s current registration is checked again. Asking for less is allowed. Asking for a scope the task does not hold is invalid_scope, even when the user and the agent would both allow it. Registrations are read on every request, so narrowing an agent’s allowed_scopes narrows the next refresh of every live task.

v0.1 issues depth 1 only. Sub-agent delegation is not in v0.1, so there is no further hop at which scope could change.

Conformance tests 2 and 3 check the rule at exchange and at refresh.

Naming scopes

Subact ID treats scope strings as opaque. It compares them as whole, space-separated tokens. Use the same strings in three places: your identity provider’s user claims, the agent registration, and the tool server that enforces them.

Name one capability on one system, such as jira:read or jira:comment. Avoid broad names like admin that nobody can interpret without reading the tool server’s code.