Add Grant Scoped Mcp Device Authorization
Artifacts
Official change artifacts tracked under openspec/.
Headless or sandboxed MCP clients can fail the normal loopback OAuth callback flow by opening a browser the user cannot operate and then waiting indefinitely. Prior-art review shows that the SLVP path for browserless setup is an explicit, bounded device-authorization flow, but PDPP's existing RFC 8628 endpoint currently issues owner-agent credentials and /mcp must reject owner bearers.
The reference AS currently advertises RFC 8628 device authorization in authorization-server metadata and serves POST /oauth/device_authorization. That endpoint is wired to ownerDeviceAuthStore and its token exchange produces owner-agent credentials. Separately, hosted /mcp is intentionally grant-scoped and rejects owner bearers.
Affected capabilities
Capability specs this change proposes to modify.
The hosted MCP endpoint SHALL treat access tokens issued by grant-scoped MCP device authorization as ordinary scoped PDPP client tokens. It SHALL continue to reject owner-agent device-flow tokens and SHALL NOT provide an owner-token fallback for MCP setup.
The reference agent access workflow SHALL direct headless or sandboxed MCP clients to a grant-scoped client authorization path. The workflow SHALL NOT tell external MCP clients or routine task-scoped agents to obtain or present an owner bearer token.
The reference authorization server SHALL distinguish owner-agent device authorization from grant-scoped MCP device authorization in public metadata, request validation, stored pending state, token exchange, and approval UI. Owner-agent device requests SHALL redeem only owner tokens. Grant-scoped MCP device requests SHALL redeem only client tokens bound to an approved PDPP grant or grant package.