Token validation

The PEP accepts a single kind of token: the one that the Xokepoint AS issued, by token exchange (headless) or by a harness login (interactive). A token issued directly by the customer IdP is rejected with 401, even if it is valid for the IdP. It has no agent, and a decision without an agent is the situation that Xokepoint exists to prevent.

The audience is the MCP ingress of the environment, <origin>/api/v1/mcp/<workspace>/<environment>: the same URL the agent calls, without the server part. A token from another environment fails here even if someone copied the keys of both.

The agent, grant and connection steps depend on state that changes after issuance. A deactivated agent, a revoked machine or consent, or a disabled identity connection cut off a token that still has minutes to live. The connection is checked again just before execution.

Only the current actor counts. A token can carry nested act claims, which record a chain of previous actors. RFC 8693 §4.1 says they are informational, and Xokepoint follows it: the decision uses only act.sub.

The 401 and the resource metadataCopy Anchor Link

Every 401 of the ingress carries WWW-Authenticate with two challenges, Bearer and DPoP with its algs (RFC 9449 §7.1). Each one names resource_metadata, the URL of the protected resource metadata of the MCP server URL (RFC 9728):

WWW-Authenticate: Bearer resource_metadata="<origin>/.well-known/oauth-protected-resource/api/v1/mcp/<workspace>/<environment>/<server>", DPoP algs="ES256", resource_metadata="<origin>/.well-known/oauth-protected-resource/api/v1/mcp/<workspace>/<environment>/<server>"

It is the well-known URL that a client builds from the MCP URL itself (RFC 9728 §3.1), so a harness that does not read the 401 first finds the same metadata. A server that does not exist or is disabled gets 404. GET, HEAD and DELETE on the MCP URL answer 405 with Allow: POST: the ingress offers no server-initiated stream and no session termination of its own.

A request with credentials also gets an error, only on the challenge of the scheme that it used. A malformed Authorization header counts as Bearer.

• invalid_token: an invalid, expired or unknown token, or a token used with the wrong scheme.
• invalid_dpop_proof: a bound token with Authorization: DPoP and a missing, duplicated, invalid or replayed proof, or a proof of another key.

The response body has the same code. invalid_dpop_proof tells the harness to send a new proof; invalid_token tells it to get a new token. The metadata gives resource (the ingress of the environment, equal to the token aud, one for all its servers), authorization_servers (the AS of the environment), bearer_methods_supported: ["header"] and dpop_signing_alg_values_supported. A coding harness starts its login from it (Connect a coding harness).

DPoPCopy Anchor Link

A token with cnf.jkt is bound to a key of the harness (RFC 9449). The PEP then requires Authorization: DPoP <token> and a DPoP header with a proof signed by the same key, and checks htm, htu, iat, ath and that the jti was not used before. A copied token without the key is refused with invalid_dpop_proof. A token without cnf keeps the Bearer scheme. The policy sees the result in context.chokepoint.binding (Trusted context).

The call URLCopy Anchor Link

The call URL carries workspace, environment and MCP server. It selects the destination and grants no access. What grants access is the policy, based on what the token proved. Only claims with a verified signature become input to the authorization request.