Skip to content

Capabilities: token endpoint body parameter, not header (and mission-less use) #35

@dickhardt

Description

@dickhardt

Summary

capabilities belongs in the token request body, not in a header. Headers are only used when there is a conflict with a pre-existing API; for the PS token endpoint, the body is the right place. §12.1's exclusion of AAuth-Capabilities on PS endpoints stands — that header is for resource calls.

Hellō's behavior is correct; the spec just needs to catch up and list capabilities as a standard token endpoint parameter alongside resource_token, justification, etc.

Mission interaction

When a request is part of a mission, the agent does not need to send capabilities again — the PS already has them from the approval flow. But the agent MAY include them if it wants to, or if they have changed since approval.

Proposed change

  • Add capabilities to the PS token endpoint request parameter list (body), alongside resource_token, justification, etc.
  • Note that within a mission, capabilities is optional; if omitted, the PS uses the values captured at approval; if present, it overrides/refreshes for this request.
  • Keep §12.1's rule that AAuth-Capabilities (the header form) is for resource calls only, not PS endpoints.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions