PACT: Private Agent Consent and Trust Profile for OAuth 2.1 and CIBA
draft-valverde-oauth-pact-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Gustavo Valverde | ||
| Last updated | 2026-04-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Zentity
Zentity |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-valverde-oauth-pact-00
Individual Submission G. Valverde
Internet-Draft Zentity
Intended status: Standards Track 18 April 2026
Expires: 20 October 2026
PACT: Private Agent Consent and Trust Profile for OAuth 2.1 and CIBA
draft-valverde-oauth-pact-00
Abstract
PACT (Private Agent Consent and Trust Profile) is a security profile
of OAuth 2.1 for privacy-preserving agent delegation. It extends
VEIL and composes OIDC CIBA Core 1.0 and OAuth Token Exchange (RFC
8693). PACT defines a durable-host plus ephemeral-session control
plane, a delegation token claim vocabulary, runtime identity proofs
using Ed25519 JWTs, capability grants with typed constraints and
usage limits, risk-graduated consent routing, and claim narrowing on
token exchange to non-agent audiences.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Valverde Expires 20 October 2026 [Page 1]
Internet-Draft PACT April 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relation to Other Work . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
2.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Compositional Architecture . . . . . . . . . . . . . . . . . 6
3.1. Five Compositional Concerns . . . . . . . . . . . . . . . 7
3.2. Runtime Participants . . . . . . . . . . . . . . . . . . 8
3.3. Three Caller Classes . . . . . . . . . . . . . . . . . . 8
4. Principal Separation . . . . . . . . . . . . . . . . . . . . 9
4.1. Durable Host . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ephemeral Session . . . . . . . . . . . . . . . . . . . . 11
4.3. Cross-Party Unlinkability . . . . . . . . . . . . . . . . 13
4.4. Trust Gradation . . . . . . . . . . . . . . . . . . . . . 14
5. Named-Action Containment . . . . . . . . . . . . . . . . . . 15
5.1. The Registry . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Grants . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Typed Constraints . . . . . . . . . . . . . . . . . . . . 16
5.4. Durable Defaults vs. Ephemeral Elevations . . . . . . . . 17
5.5. Temporal and Cumulative Limits . . . . . . . . . . . . . 18
6. Risk-Proportional Consent . . . . . . . . . . . . . . . . . . 19
6.1. CIBA as Correlation Point . . . . . . . . . . . . . . . . 19
6.2. Three Routing Outcomes . . . . . . . . . . . . . . . . . 19
6.3. Runtime Proof . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Biometric Approval Strength . . . . . . . . . . . . . . . 22
6.5. Capability Derivation . . . . . . . . . . . . . . . . . . 23
7. Delegation Evidence . . . . . . . . . . . . . . . . . . . . . 23
7.1. The Delegation Token Profile . . . . . . . . . . . . . . 24
7.2. Chain Tracking . . . . . . . . . . . . . . . . . . . . . 27
8. Claim Narrowing on Token Exchange . . . . . . . . . . . . . . 28
8.1. Dropping Agent Control-Plane Claims . . . . . . . . . . . 28
8.2. Privilege Reduction . . . . . . . . . . . . . . . . . . . 28
8.3. Request and Response . . . . . . . . . . . . . . . . . . 29
9. Temporal Boundaries . . . . . . . . . . . . . . . . . . . . . 30
9.1. Two Independent Clocks . . . . . . . . . . . . . . . . . 30
9.2. No Reactivation . . . . . . . . . . . . . . . . . . . . . 30
Valverde Expires 20 October 2026 [Page 2]
Internet-Draft PACT April 2026
9.3. Renewal Through Use . . . . . . . . . . . . . . . . . . . 31
9.4. Revocation Cascade . . . . . . . . . . . . . . . . . . . 31
10. Machine-Readable Surfaces . . . . . . . . . . . . . . . . . . 31
10.1. Agent Configuration Document . . . . . . . . . . . . . . 32
10.2. Capability Discovery . . . . . . . . . . . . . . . . . . 32
10.3. Introspection with Lifecycle . . . . . . . . . . . . . . 32
10.4. A2A Agent Card (Informational) . . . . . . . . . . . . . 33
11. Cryptographic Continuity . . . . . . . . . . . . . . . . . . 33
11.1. The Full Chain . . . . . . . . . . . . . . . . . . . . . 33
11.2. Session Binding . . . . . . . . . . . . . . . . . . . . 35
11.3. Host Binding . . . . . . . . . . . . . . . . . . . . . . 35
11.4. Runtime Binding . . . . . . . . . . . . . . . . . . . . 35
11.5. Consent Binding . . . . . . . . . . . . . . . . . . . . 35
11.6. Disclosure Binding . . . . . . . . . . . . . . . . . . . 35
11.7. Delegation Binding . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. JTI Replay Protection . . . . . . . . . . . . . . . . . 36
12.2. Algorithm Confusion Prevention . . . . . . . . . . . . . 36
12.3. JWKS Fetch Hardening . . . . . . . . . . . . . . . . . . 36
12.4. Host Key Security . . . . . . . . . . . . . . . . . . . 36
12.5. Session Key Ephemerality . . . . . . . . . . . . . . . . 36
12.6. Task Description Sensitivity . . . . . . . . . . . . . . 36
12.7. DPoP Binding . . . . . . . . . . . . . . . . . . . . . . 37
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
13.1. Cross-RP Agent Correlation . . . . . . . . . . . . . . . 37
13.2. PII in Tokens . . . . . . . . . . . . . . . . . . . . . 37
13.3. Metadata Minimization . . . . . . . . . . . . . . . . . 37
13.4. Pairwise Opt-Out . . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
14.1. Media Type Registrations . . . . . . . . . . . . . . . . 38
14.2. Well-Known URI Registration . . . . . . . . . . . . . . 38
14.3. HTTP Field Name Registrations . . . . . . . . . . . . . 38
14.4. JWT Claim Registrations . . . . . . . . . . . . . . . . 39
14.5. OAuth Extensions Error Registry . . . . . . . . . . . . 39
14.6. ACR Values . . . . . . . . . . . . . . . . . . . . . . . 39
15. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Server Requirements . . . . . . . . . . . . . . . . . . 40
15.2. Client Requirements . . . . . . . . . . . . . . . . . . 40
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
16.1. Normative References . . . . . . . . . . . . . . . . . . 41
16.2. Informative References . . . . . . . . . . . . . . . . . 43
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
Valverde Expires 20 October 2026 [Page 3]
Internet-Draft PACT April 2026
1. Introduction
An agent acting on behalf of a human needs three properties at once:
machine authentication (the caller proves it is a specific runtime,
not merely the application that launched it), human consent (the
human approves sensitive actions through a channel the agent cannot
subvert), and privacy-preserving delegation (the relying party learns
who acted without receiving a globally trackable identifier).
Existing specifications cover each property in isolation. CIBA
[CIBA-Core] provides a backchannel consent channel. DPoP [RFC9449]
sender-constrains tokens. RAR [RFC9396] carries structured
authorization payloads. Token Exchange [RFC8693] rebinds audience
and scope. PACT specifies how agent identity, human consent, and
token issuance compose into a single delegation flow.
The profile composes and constrains the following specifications:
+===============+================================================+
| Concern | Specifications |
+===============+================================================+
| Secure | OAuth 2.1 [I-D.ietf-oauth-v2-1], PKCE |
| Transport | [RFC7636], PAR [RFC9126], DPoP [RFC9449] |
+---------------+------------------------------------------------+
| Structured | Rich Authorization Requests [RFC9396] |
| Intent | |
+---------------+------------------------------------------------+
| Agent Control | PACT (this document), OAuth Client Attestation |
| Plane | [I-D.ietf-oauth-attestation-based-client-auth] |
+---------------+------------------------------------------------+
| Consent | CIBA [CIBA-Core] |
| Channel | |
+---------------+------------------------------------------------+
| Token | Token Exchange [RFC8693], Token Introspection |
| Semantics | [RFC7662], OIDC Core Pairwise Identifiers |
| | [OIDC-Core] |
+---------------+------------------------------------------------+
Table 1
This document specifies: pairwise agent identifiers (Section 4.3),
risk-graduated consent routing (Section 6), usage-limited capability
grants (Section 5.5), cryptographic binding chains (Section 11),
ephemeral identity disclosure, and claim narrowing on token exchange
(Section 8).
Valverde Expires 20 October 2026 [Page 4]
Internet-Draft PACT April 2026
1.1. Relation to Other Work
Several concurrent individual submissions address overlapping parts
of the agent-delegation problem. The Agent Auth Protocol [AAP] and
[I-D.aap-oauth-profile] define a JWT claim vocabulary for agent-
acting-as-user semantics; PACT aligns with their claim names where
they coincide. [I-D.oauth-ai-agents-on-behalf-of-user] explores the
subject model when an agent acts on behalf of an authenticated user;
PACT's session identity and act.sub derivation build on the same
premise. The Agent-to-Agent Protocol [A2A] covers agent-to-agent
discovery and card exchange, which complements the consent and token
profile defined here. PACT's scope is narrower than any of these: it
specifies CIBA binding, typed-constraint capability grants, and claim
narrowing on token exchange to non-agent audiences.
2. Conventions and Terminology
2.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Versioning
PACT uses MAJOR.MINOR versioning, with -draft appended for pre-
release revisions. Implementations MUST reject configurations or
discovery documents with an unrecognized major version.
Implementations SHOULD accept documents with a higher minor version
than expected and ignore unrecognized fields, preserving forward
compatibility.
2.3. Definitions
Agent Session: An ephemeral runtime identity for one live process.
Each session holds its own Ed25519 keypair. The private key
exists only in process memory.
Agent-Assertion: A short-lived EdDSA JWT (typ: agent-assertion+jwt)
signed by the session private key, proving possession of the
runtime identity at the time of a consent request.
Approval Strength: A capability-level declaration of the minimum
consent mechanism required: none (auto-approve), session (active
user interaction), or biometric (unforgeable user verification).
Valverde Expires 20 October 2026 [Page 5]
Internet-Draft PACT April 2026
Authorization Server (AS): The server that implements this profile,
managing identity registration, capability grants, consent
routing, and token issuance.
Binding Chain: The sequence of cryptographic proofs connecting an
OAuth user token through host registration, session registration,
runtime assertion, human consent, and delegated token issuance.
Capability: A server-defined named action with optional JSON Schema
for input and output, and a required approval strength. PACT's
unit of authorization.
Capability Grant: An authorization record linking one agent session
to one capability, with optional typed constraints, usage limits,
and an expiration time.
Client: The process that holds the host identity, manages keys,
signs JWTs, and presents tools to the agent runtime.
Constraint: A typed restriction on a grant's input parameters.
Operators: eq, min, max, in, not_in.
Durable Host: The persistent installation identity for a client
environment. Survives across process restarts. Holds an Ed25519
keypair persisted to disk.
Host Policy: A durable capability grant attached to a host rather
than a session. Survives session expiry and seeds new sessions.
Pairwise Agent Identifier: A per-relying-party pseudonym derived
from the session ID and the RP's sector identifier, preventing
cross-RP agent correlation.
Relying Party (RP): A service that receives and validates delegated
agent tokens.
Session Grant: An ephemeral capability grant attached to one agent
session. Seeded from host policies at registration; may be
elevated via consent.
Usage Ledger: An append-only record of capability executions, used
to enforce daily limits and cooldowns atomically.
3. Compositional Architecture
Valverde Expires 20 October 2026 [Page 6]
Internet-Draft PACT April 2026
3.1. Five Compositional Concerns
PACT's constituent standards group into five concerns: secure
transport, structured intent, agent control plane, consent channel,
and token semantics. Each concern produces inputs for the next, from
machine authentication through human approval to token issuance and
relying-party verification.
+--------------------+ +--------------------+
| Structured Intent | | Agent Control |
| RAR (RFC 9396) | | Plane: Host/ |
| | | Session identity, |
| | | Capability grants, |
| | | Agent-Assertion |
+---------+----------+ +---------+----------+
| |
| what to approve | who is asking
v v
+------------------------------------------------+
| Consent Channel: CIBA |
| Risk-graduated routing |
+------------------------+-----------------------+
|
+------+------+
| approved |
| token |
v |
+------------------------------------------------+
| Token Semantics |
| Token Exchange (RFC 8693), Introspection |
| (RFC 7662), Pairwise identifiers, PACT |
| delegation claims |
+------------------------------------------------+
^
| protects channel (below all)
|
+------------------------------------------------+
| Secure Transport: OAuth 2.1, PKCE, PAR, DPoP |
+------------------------------------------------+
Secure Transport sits beneath the other four concerns because
removing any transport spec changes security properties, not the
agent model. DPoP is the one transport spec that crosses into agent
territory: when token exchange mints a downstream token from a CIBA
access token, DPoP re-binds the issued token to the caller's proof-
of-possession key.
Valverde Expires 20 October 2026 [Page 7]
Internet-Draft PACT April 2026
Structured Intent carries typed payloads through the flow. RAR
(authorization_details) is submitted on the CIBA request, retained on
the CIBA request record during consent evaluation, and projected onto
downstream exchanged tokens (Section 8). The approved typed payload
does not appear on the CIBA-issued access token itself.
Agent Control Plane establishes who is asking. It produces two
outputs: the Agent-Assertion JWT that enters the consent channel as
runtime proof, and the capability grants that determine whether
consent can short-circuit into automatic approval.
Consent Channel carries the human approval interaction. CIBA binds
the runtime proof to a specific consent request. The CIBA
auth_req_id serves as the trace identifier correlating agent
identity, consent, and token issuance.
Token Semantics encodes the authorized delegation. Token exchange
rebinds audience and recomputes pairwise identifiers. Introspection
re-evaluates session lifecycle at query time.
3.2. Runtime Participants
+===============+=================================================+
| Role | Function |
+===============+=================================================+
| Agent | The AI actor scoped to a conversation, task, or |
| | session. Does not hold keys directly. |
+---------------+-------------------------------------------------+
| Client | Process holding the host identity; manages |
| | keys, signs JWTs, presents tools. |
+---------------+-------------------------------------------------+
| Authorization | Manages registrations, capability grants, |
| Server | consent routing, and token issuance. |
+---------------+-------------------------------------------------+
| Relying Party | Receives delegated tokens; validates agent |
| | identity via introspection or JWT verification. |
+---------------+-------------------------------------------------+
| User | The human principal who approves sensitive |
| | actions via CIBA. |
+---------------+-------------------------------------------------+
Table 2
3.3. Three Caller Classes
PACT distinguishes three caller classes by authentication mode and
scope.
Valverde Expires 20 October 2026 [Page 8]
Internet-Draft PACT April 2026
+================+============================+====================+
| Caller | Authentication | Scope |
+================+============================+====================+
| Browser user | Session cookie | Dashboard and |
| | | browser-only |
| | | surfaces |
+----------------+----------------------------+--------------------+
| User-delegated | OAuth access token | Agent host/session |
| machine | exchanged into a dedicated | registration, |
| | DPoP-bound bootstrap token | revocation |
+----------------+----------------------------+--------------------+
| Pure machine | client_credentials access | Introspection, |
| client | token | resource-server |
| | | APIs |
+----------------+----------------------------+--------------------+
Table 3
Registration, introspection, and token exchange are machine-facing
OAuth surfaces; human consent is obtained separately through CIBA
(Section 6). A client bootstrapping an agent host MUST NOT reuse a
login token for registration: it MUST first exchange that token for a
DPoP-bound bootstrap token carrying narrow agent scopes
(Section 4.1).
4. Principal Separation
PACT separates agent identity into three layers with distinct
lifetimes and audiences. The host is durable (persistent across
process restarts). The session is ephemeral (fresh per runtime
instance, enabling per-session audit). The pairwise identifier shown
to each relying party is uncorrelatable across services.
4.1. Durable Host
A host is the persistent installation identity for a client
environment. It represents a specific installation on a specific
machine, not a user or an application.
Bootstrap. The client first exchanges its pairwise login token via
Token Exchange [RFC8693] for a short-lived DPoP-bound bootstrap token
carrying agent:host.register. POST {host_registration_endpoint}
authenticates with that bootstrap token, not the login token.
Identity properties:
Valverde Expires 20 October 2026 [Page 9]
Internet-Draft PACT April 2026
+=============+======================================+
| Property | Value |
+=============+======================================+
| Key type | Ed25519 [RFC8037] |
+-------------+--------------------------------------+
| Identity | JWK Thumbprint [RFC7638], SHA-256 |
| anchor | |
+-------------+--------------------------------------+
| Persistence | Client-side file, server-side record |
+-------------+--------------------------------------+
| Uniqueness | One thumbprint per (user, client) |
| | pair. Same user and client MAY have |
| | multiple hosts (different machines). |
+-------------+--------------------------------------+
| Binding | A host key MUST NOT be rebound |
| | across users or OAuth clients. |
+-------------+--------------------------------------+
Table 4
Key storage. The client MUST persist the host keypair in a namespace
derived from the server URL, OAuth client ID, and the authenticated
account subject (or another stable per-user identifier):
~/.zentity/hosts/
<SHA-256(serverUrl + ":" + clientId + ":" + accountSub)>.json
The file MUST be stored with mode 0600. The directory MUST be
created with mode 0700.
Attestation. Host registration MAY include vendor attestation
headers per [I-D.ietf-oauth-attestation-based-client-auth]:
* OAuth-Client-Attestation: a JWT signed by a trusted vendor,
containing a cnf.jwk matching the host's public key.
* OAuth-Client-Attestation-PoP: a proof-of-possession JWT signed by
the host's private key.
The server verifies attestation JWTs against a pre-configured set of
trusted issuer JWKS URLs. Verification uses a hardened JWKS fetcher
that rejects unsafe remote key sources (private/loopback IPs, non-
HTTPS in production, responses exceeding a fixed size cap, long
timeouts).
Attestation results in an elevated trust tier that widens default
host policy (Section 5.4).
Valverde Expires 20 October 2026 [Page 10]
Internet-Draft PACT April 2026
4.2. Ephemeral Session
An agent session is the runtime identity for one live process. Each
session holds its own Ed25519 keypair. The private key MUST exist
only in process memory, and MUST NOT be persisted to disk.
Registration. POST {registration_endpoint} with the bootstrap token
carrying agent:session.register and a host attestation JWT.
The host attestation JWT (typ: host-attestation+jwt) proves the
client possesses the durable host key:
{
"typ": "host-attestation+jwt",
"alg": "EdDSA"
}
.
{
"iss": "<hostId>",
"sub": "agent-registration",
"iat": 1711000000,
"exp": 1711000060
}
This JWT MUST be signed with the host's Ed25519 private key and MUST
expire within 60 seconds.
Registration sequence:
Valverde Expires 20 October 2026 [Page 11]
Internet-Draft PACT April 2026
Client Authorization Server
| |
| 1. Exchange login token for bootstrap token |
| scope: agent:host.register |
| agent:session.register |
| agent:session.revoke |
|--------------------------------------------->|
| |
| 2. DPoP bootstrap token |
|<---------------------------------------------|
| |
| 3. POST /host/register |
| Authorization: DPoP <bootstrap> |
| { publicKey, name } |
|--------------------------------------------->|
| compute JWK |
| thumbprint; |
| upsert host |
| { hostId, attestation_tier } |
|<---------------------------------------------|
| |
| 4. Generate fresh session keypair |
| 5. Sign host-attestation+jwt |
| |
| 6. POST /register |
| Authorization: DPoP <bootstrap> |
| { hostJwt, agentPublicKey, ... } |
|--------------------------------------------->|
| verify host JWT; |
| seed defaults; |
| create session; |
| copy host-> |
| session grants |
| { sessionId, status, grants } |
|<---------------------------------------------|
Identity hierarchy:
Valverde Expires 20 October 2026 [Page 12]
Internet-Draft PACT April 2026
+---------------------+
| User |
| (human principal) |
+----------+----------+
|
+----------v----------+
| Host |
| durable install, |
| Ed25519 on disk |
+----------+----------+
|
+---------------+-----------------+
| | |
+---------v------+ +------v--------+ +------v--------+
| Agent Session | | Agent Session | | Host Policies |
| A | | B | | durable |
| Ed25519 in mem | |Ed25519 in mem | | defaults |
+-------+--------+ +------+--------+ +---------------+
| |
+-------v--------+ +------v--------+
| Session Grants | | Session Grants|
+----------------+ +---------------+
4.3. Cross-Party Unlinkability
Agent identifiers in delegated tokens MUST be pairwise per relying
party by default. Without pairwise derivation, the session
identifier would travel to every relying party as a stable cross-
service correlator.
Derivation:
act.sub = MAC(PAIRWISE_SECRET, sector + "." + sessionId)
Where:
* MAC is a keyed message authentication code with at least 128 bits
of output. HMAC-SHA-256 meets this requirement.
* PAIRWISE_SECRET is a server-side secret of at least 32 bytes.
* sector is the RP's registered sector identifier, following the
same mechanism used for user pairwise sub in VEIL
[I-D.valverde-oauth-veil]. Deployments that do not yet support
sector_identifier_uri MUST still enforce a stable single-host
registration rule so the derived sector remains deterministic.
* sessionId is the internal agent session identifier.
Valverde Expires 20 October 2026 [Page 13]
Internet-Draft PACT April 2026
Properties:
* Two RPs receiving tokens from the same agent session see different
act.sub values.
* The same derivation applies to agent.id in the PACT delegation
claim set.
* Deployments that need global agent tracking MUST use an agent-
specific client setting distinct from VEIL's user-facing
subject_type. Reusing subject_type would disable pairwise user
identifiers at the same time.
* Pairwise derivation uses the session ID (not host ID) because the
acting principal is the runtime session, not the installation.
4.4. Trust Gradation
Host attestation assigns a host to one of two trust tiers.
Attestation widens the default host policy but does not create a
separate token class or silently widen identity-disclosure
capabilities.
+============+==========================+=========================+
| Tier | How reached | Effect on default host |
| | | policy |
+============+==========================+=========================+
| unverified | Default registration | check_compliance, |
| | | request_approval |
+------------+--------------------------+-------------------------+
| attested | Valid OAuth-Client- | Same default capability |
| | Attestation + PoP | floor; trust tier is |
| | | surfaced in UI, tokens, |
| | | and introspection |
+------------+--------------------------+-------------------------+
Table 5
A host's attestation tier is recorded at registration and surfaces in
the approval UI (for example, "Verified by <vendor>" versus
"Unverified agent"), in token claims (agent.runtime.attested: true/
false), and in introspection responses.
Valverde Expires 20 October 2026 [Page 14]
Internet-Draft PACT April 2026
5. Named-Action Containment
Capability-based authorization determines whether a session can
perform an action without interrupting the user. The registry
defines named actions, grants bind them to sessions, constraints
restrict parameters, and the usage ledger enforces temporal and
cumulative limits.
5.1. The Registry
Capabilities are server-defined named actions. Each capability
declares:
+===================+========+==========+===================+
| Field | Type | Required | Description |
+===================+========+==========+===================+
| name | string | Yes | Stable snake_case |
| | | | identifier |
+-------------------+--------+----------+-------------------+
| description | string | Yes | Human-readable |
| | | | description |
+-------------------+--------+----------+-------------------+
| input_schema | JSON | No | Expected input |
| | Schema | | parameters |
+-------------------+--------+----------+-------------------+
| output_schema | JSON | No | Expected output |
| | Schema | | shape |
+-------------------+--------+----------+-------------------+
| approval_strength | enum | Yes | none, session, or |
| | | | biometric |
+-------------------+--------+----------+-------------------+
Table 6
Discovery. GET {capabilities_endpoint} returns the full registry.
No authentication required.
5.2. Grants
A grant links one agent session (or host) to one capability with
optional constraints, usage limits, and an expiration time.
Valverde Expires 20 October 2026 [Page 15]
Internet-Draft PACT April 2026
+====================+===========+==================================+
| Field | Type | Description |
+====================+===========+==================================+
| capability_name | string | The capability being granted |
+--------------------+-----------+----------------------------------+
| status | enum | pending, active, denied, |
| | | revoked |
+--------------------+-----------+----------------------------------+
| constraints | object | Typed constraint operators |
| | | (Section 5.3) |
+--------------------+-----------+----------------------------------+
| daily_limit_count | integer | Max executions per 24-hour |
| | | window |
+--------------------+-----------+----------------------------------+
| daily_limit_amount | number | Max cumulative amount per |
| | | 24-hour window |
+--------------------+-----------+----------------------------------+
| cooldown_sec | integer | Minimum seconds between |
| | | executions |
+--------------------+-----------+----------------------------------+
| source | string | host_policy, session_elevation, |
| | | or user_grant |
+--------------------+-----------+----------------------------------+
| expires_at | timestamp | Per-grant TTL, independent of |
| | | session TTL |
+--------------------+-----------+----------------------------------+
Table 7
5.3. Typed Constraints
Constraints restrict the input values a grant authorizes. They use
the input schema field names as keys.
Valverde Expires 20 October 2026 [Page 16]
Internet-Draft PACT April 2026
+==========+========+=========================================+
| Operator | Type | Semantics |
+==========+========+=========================================+
| max | number | Value MUST be <= max |
+----------+--------+-----------------------------------------+
| min | number | Value MUST be >= min |
+----------+--------+-----------------------------------------+
| eq | any | Value MUST equal the constraint value |
+----------+--------+-----------------------------------------+
| in | array | Value MUST be a member of the array |
+----------+--------+-----------------------------------------+
| not_in | array | Value MUST NOT be a member of the array |
+----------+--------+-----------------------------------------+
Table 8
Within one grant, all constraints are AND (all must pass). Across
multiple grants for the same capability, the first matching active
grant wins (OR).
Constraint extraction. For capability evaluation, the server
extracts constraint-matchable values from authorization_details
[RFC9396]. The type field maps to a capability name. Nested fields
use dot notation (amount.value, amount.currency).
Bidirectional negotiation. The agent proposes constraints at
registration, and the server or user can narrow them. The server
MUST NOT widen constraints beyond what the agent proposed without a
new approval.
Unknown operators. If a grant contains an unrecognized constraint
operator, the server MUST reject the evaluation with a
constraint_violated error.
5.4. Durable Defaults vs. Ephemeral Elevations
The policy model is split for the same reason identity is split:
durable defaults and per-runtime elevations have different lifetimes
and different trust properties.
Host policies are durable and host-scoped. They survive across
sessions, are seeded by defaults or attestation tier, carry
constraints and usage limits, and are modified only by the user or
server admin.
Valverde Expires 20 October 2026 [Page 17]
Internet-Draft PACT April 2026
Session grants are ephemeral and session-scoped. They belong to one
live session, are copied from host policies at session registration
(status: active), are created as pending elevations for requested
capabilities beyond defaults (status: pending), and expire when the
session expires or is revoked.
Seeding sequence at session registration:
1. Ensure the capability registry is populated.
2. Ensure default host policies exist for the host's trust tier.
3. Copy all active host policies into active session grants (source:
host_policy).
4. Create pending session grants for requested capabilities not in
the defaults (source: session_elevation).
5.5. Temporal and Cumulative Limits
The usage ledger is an append-only table recording each approved
execution. It enforces limits on execution frequency and cumulative
totals, independent of the per-request constraint checks in
Section 5.3.
Scope determination. Usage is scoped to the narrowest applicable
boundary:
* If the grant is backed by a host policy: scope to the host policy
(shared across sessions).
* If the grant is session-specific: scope to the session grant.
* Fallback: scope to the session.
Enforcement sequence (within a single database transaction):
1. Cooldown check. Query the ledger for any execution within
cooldown_sec of now. If found, reject.
2. Daily count check. Count executions in the last 24 hours. If
count >= daily_limit_count, reject.
3. Daily amount check. Sum amount in the last 24 hours. If sum +
request.amount > daily_limit_amount, reject.
4. Record. Insert a new ledger entry. Return success.
Valverde Expires 20 October 2026 [Page 18]
Internet-Draft PACT April 2026
The transaction ensures atomicity; two concurrent requests cannot
both pass a limit that only has room for one.
6. Risk-Proportional Consent
At runtime, a delegation request must be routed to one of three
outcomes: auto-approved (within pre-authorized limits), interactive
approval (user prompt required), or denied. PACT uses CIBA as the
transport and defines the routing logic that selects the outcome.
6.1. CIBA as Correlation Point
The CIBA auth_req_id correlates agent identity (from the control
plane), human consent (from the approval interaction), token issuance
(from the token endpoint), and the audit trail (from the usage
ledger). An Agent-Assertion JWT MUST be bound to a specific
auth_req_id; it MUST NOT be accepted as general runtime
authentication outside the CIBA request it carries.
6.2. Three Routing Outcomes
The consent router produces three outcomes based on the capability's
approval_strength and the agent's session grants. They differ along
one axis: how much human involvement is required.
+===========+======================+============================+
| Outcome | When | Human interruption |
+===========+======================+============================+
| Silent | Active grant exists, | None |
| approval | constraints pass, | |
| | limits not exceeded, | |
| | and capability | |
| | strength is none | |
+-----------+----------------------+----------------------------+
| Session | No matching grant, | Push notification with |
| approval | or strength is | inline approve/deny |
| | session | |
+-----------+----------------------+----------------------------+
| Biometric | Capability strength | Push notification with |
| approval | is biometric | "Open to approve" link |
| | | only; WebAuthn |
| | | userVerification: required |
| | | on the approval page |
+-----------+----------------------+----------------------------+
Table 9
Valverde Expires 20 October 2026 [Page 19]
Internet-Draft PACT April 2026
What silent approval can never do. The evaluator MUST refuse
automatic approval in these cases:
* Any request containing identity scopes (scopes that would release
PII).
* Any request whose derived capability is missing from the registry.
* Any capability whose approval strength is biometric.
* Any request without an active matching grant.
* Any request that exceeds cooldown or daily limits.
6.3. Runtime Proof
Before requesting consent, the client signs an Agent-Assertion JWT
with the session's Ed25519 private key:
{
"typ": "agent-assertion+jwt",
"alg": "EdDSA"
}
.
{
"iss": "<sessionId>",
"jti": "<unique>",
"iat": 1711000000,
"exp": 1711000060,
"host_id": "<hostId>",
"task_id": "<unique task identifier>",
"task_hash": "<SHA-256 hex of binding_message>"
}
The assertion is placed in the Agent-Assertion HTTP header on the
CIBA backchannel authorize request.
binding_message is the OIDC CIBA Core 1.0 [CIBA-Core] request
parameter, defined there as a human-readable display value. PACT
retains its human-visible role in the approval UI and additionally
requires that a binding_message be present whenever an Agent-
Assertion is present. The task_hash claim is defined as SHA-
256(binding_message), giving the agent cryptographic commitment to
the same string the human will see. An assertion whose task_hash
does not match the CIBA request's binding_message MUST NOT produce
agent-bound token semantics.
Verification sequence:
Valverde Expires 20 October 2026 [Page 20]
Internet-Draft PACT April 2026
1. Decode payload without verification to extract iss (= sessionId).
2. Load session from the database.
3. Verify session status is active.
4. Import session's stored public key.
5. Verify JWT signature with algorithms: ["EdDSA"].
6. Verify typ header is agent-assertion+jwt.
7. Compute session lifecycle state (Section 9). Reject if not
active.
8. Compute SHA-256(binding_message) and compare to task_hash. MUST
match.
9. Verify host ownership: the session's host MUST belong to the same
user and OAuth client as the CIBA request.
Binding to CIBA request. On successful verification, the server
snapshots server-owned metadata onto the CIBA request record:
+=======================================+=========================+
| Field | Source |
+=======================================+=========================+
| agent_session_id | Session record |
+---------------------------------------+-------------------------+
| host_id | Session's parent host |
+---------------------------------------+-------------------------+
| display_name, runtime, model, version | Session registration |
| | metadata |
+---------------------------------------+-------------------------+
| task_id, task_hash | Agent-Assertion claims |
+---------------------------------------+-------------------------+
| assertion_verified | true |
+---------------------------------------+-------------------------+
| pairwise_act_sub | Derived for the |
| | requesting OAuth client |
+---------------------------------------+-------------------------+
| attestation_provider, | Host attestation |
| attestation_tier | metadata |
+---------------------------------------+-------------------------+
Table 10
Valverde Expires 20 October 2026 [Page 21]
Internet-Draft PACT April 2026
This snapshot ties the later token to the actual registered runtime,
not a free-form claim supplied by the client.
CIBA request integrity. Three additional security properties apply
to CIBA requests in PACT:
1. Release handle binding. The CIBA release handle (used to
exchange an approved request for tokens) MUST be
cryptographically bound to (userId, authReqId, clientId). A
handle obtained from one request MUST NOT redeem a different
request.
2. Atomic status transitions. The transition from approved to
redeemed MUST use compare-and-swap semantics. Concurrent polling
attempts that race the transition MUST fail rather than
duplicate-issue tokens.
3. Entropy. auth_req_id values MUST be generated with cryptographic
entropy sufficient to prevent enumeration (e.g., UUID v4).
6.4. Biometric Approval Strength
An agent with browser control (for example, Playwright or an MCP
browser tool) can navigate to approval URLs and click buttons. The
biometric approval strength defends against self-approval by
requiring WebAuthn userVerification: required, a biometric or PIN
gesture that the agent cannot produce.
For biometric-strength capabilities:
* Push notifications show "Open to approve" link only; inline
approve/deny actions are disabled because they cannot trigger
WebAuthn.
* The approval endpoint returns a WebAuthn challenge that MUST be
satisfied before the approval is accepted.
* Password-based session re-authentication is insufficient because
the agent may know the password.
The session strength accepts any in-session re-authentication an
agent with browser access could automate (cookie presence, password
re-entry). The biometric strength requires a WebAuthn user-
verification ceremony that cannot be performed without the registered
authenticator.
Valverde Expires 20 October 2026 [Page 22]
Internet-Draft PACT April 2026
Identity scope exception. When a CIBA request includes identity
scopes, push notifications MUST NOT include inline approve actions,
even for session-strength capabilities. Vault unlock (required by
VEIL for identity claim delivery) cannot be triggered from a service
worker or agent browser context, making identity-scoped requests
functionally equivalent to biometric for inline approval purposes.
The user MUST navigate to the approval page in a full browser
context.
6.5. Capability Derivation
The consent router derives a capability name from the CIBA request's
authorization_details and scope:
+=========================================+====================+
| Condition | Derived capability |
+=========================================+====================+
| Any detail has type equal to "purchase" | purchase |
+-----------------------------------------+--------------------+
| Any scope is an identity scope | read_profile |
+-----------------------------------------+--------------------+
| Any scope is a proof scope (for example | check_compliance |
| proof:age or proof:compliance) | |
+-----------------------------------------+--------------------+
| Only openid scope, no typed details | request_approval |
+-----------------------------------------+--------------------+
Table 11
The first matching row wins. The precedence order is purchase
details, then identity scopes, then proof scopes, then openid-only
requests. A mixed request (for example, purchase details plus
identity.* scopes) is routed to the most sensitive derived
capability.
7. Delegation Evidence
Approved delegations are encoded as JWT access tokens. The sub and
act claims identify the user and agent principals. The capabilities,
oversight, audit, and delegation claims describe the constraints and
provenance.
Valverde Expires 20 October 2026 [Page 23]
Internet-Draft PACT April 2026
7.1. The Delegation Token Profile
Access tokens issued after agent-verified CIBA approval carry the
delegation claim set defined below. The act claim is used as
specified in [RFC8693] Section 4.1. The remaining claims (agent,
task, capabilities, oversight, audit, delegation) are defined
normatively in this document. Approved authorization_details
[RFC9396] are retained on the CIBA request record and projected onto
exchanged tokens (Section 8), not on the CIBA-issued access token.
{
"iss": "https://as.example.com",
"sub": "<pairwise user id for RP>",
"aud": "<RP client_id>",
"exp": 1711003600,
"iat": 1711000000,
"jti": "<unique>",
"scope": "openid purchase",
"act": {
"sub": "<pairwise agent id for RP>"
},
"agent": {
"id": "<pairwise agent id for RP>",
"type": "mcp-agent",
"model": {
"id": "claude-sonnet-4-20250514",
"version": "1.0.0"
},
"runtime": {
"environment": "node",
"attested": true
}
},
"task": {
"id": "task-uuid",
"purpose": "purchase"
},
"capabilities": [
{
"action": "purchase",
"constraints": [
{ "field": "amount.value", "op": "max", "value": 100 }
]
}
Valverde Expires 20 October 2026 [Page 24]
Internet-Draft PACT April 2026
],
"oversight": {
"approval_reference": "<auth_req_id>",
"requires_human_approval_for": ["identity.*"]
},
"audit": {
"trace_id": "<auth_req_id>",
"session_id": "<pairwise agent id for RP>"
},
"cnf": {
"jkt": "<DPoP key thumbprint>"
}
}
Claim semantics:
Valverde Expires 20 October 2026 [Page 25]
Internet-Draft PACT April 2026
+=======================================+==========================+
| Claim | Semantics |
+=======================================+==========================+
| sub | Pairwise user identifier |
| | for the target RP |
+---------------------------------------+--------------------------+
| act.sub | Pairwise agent session |
| | identifier for the |
| | target RP |
+---------------------------------------+--------------------------+
| agent.id | Same as act.sub, |
| | pairwise agent |
| | identifier |
+---------------------------------------+--------------------------+
| agent.type | Agent runtime type |
| | (e.g., mcp-agent) |
+---------------------------------------+--------------------------+
| agent.model | Model metadata |
| | (informational, not |
| | security-critical) |
+---------------------------------------+--------------------------+
| agent.runtime.attested | Whether the host passed |
| | vendor attestation |
+---------------------------------------+--------------------------+
| task.id | Task identifier from the |
| | Agent-Assertion |
+---------------------------------------+--------------------------+
| task.purpose | Category-level intent |
| | (not verbatim |
| | description) |
+---------------------------------------+--------------------------+
| capabilities | Approved capabilities |
| | with their constraint |
| | snapshot |
+---------------------------------------+--------------------------+
| oversight.requires_human_approval_for | Scopes that MUST route |
| | through human approval |
+---------------------------------------+--------------------------+
| audit.trace_id | CIBA auth_req_id for |
| | end-to-end correlation |
+---------------------------------------+--------------------------+
| cnf.jkt | DPoP proof-of-possession |
| | key thumbprint |
+---------------------------------------+--------------------------+
Table 12
Valverde Expires 20 October 2026 [Page 26]
Internet-Draft PACT April 2026
Conditional emission. If assertion_verified is false on the CIBA
request, delegation claims MUST NOT be emitted; the token is issued
as a standard CIBA token without agent semantics.
7.2. Chain Tracking
When tokens are exchanged via Token Exchange [RFC8693], the
delegation claim tracks the chain:
{
"delegation": {
"depth": 1,
"max_depth": 3,
"chain": ["<pairwise-agent-A>", "<pairwise-agent-B>"],
"parent_jti": "<original-token-jti>"
}
}
Rules enforced on token exchange:
* The server MUST maintain delegation lineage in canonical internal
actor references (for example, raw session IDs), not only in the
audience-projected identifiers emitted in tokens.
* depth incremented by 1 on each exchange.
* Current actor appended to the canonical lineage before projection.
* delegation.chain in the exchanged token MUST be projected for the
current audience from the canonical lineage. Previous audience-
specific pairwise values MUST NOT be copied verbatim into a new
audience context.
* Implementations advertising delegation_chains: true MUST reject
the exchange if depth >= max_depth.
* Implementations advertising delegation_chains: true MUST enforce
mandatory privilege reduction: at least one of narrower
capabilities, tighter constraints, shorter TTL, or lower
max_depth.
* The first exchange from a CIBA access token to a non-agent
audience satisfies privilege reduction by applying the claim-
narrowing rules of Section 8: the issued token omits the
delegation agent, task, capabilities, oversight, and audit
sections, narrows authorization_details to the approved subset,
and rebinds audience. If delegation_chains is false, the issued
token MAY omit delegation as well; if delegation_chains is true,
Valverde Expires 20 October 2026 [Page 27]
Internet-Draft PACT April 2026
it MUST retain the projected delegation lineage needed for depth
enforcement and family revocation. The issued token lifetime MUST
NOT exceed the subject token's remaining lifetime.
Family revocation. Revoking a parent token (by jti) revokes all
descendants reachable via parent_jti graph traversal.
8. Claim Narrowing on Token Exchange
When delegation evidence must cross an audience boundary, the AS uses
Token Exchange [RFC8693] to mint a downstream token for the new
audience. This section specifies what the AS MUST strip, project,
and attenuate on every such exchange. The rules apply regardless of
the requested_token_type; PACT does not mint any profile-specific
artifact type.
8.1. Dropping Agent Control-Plane Claims
When the target audience is not itself an agent (the common case: a
resource server or relying party consuming the delegated
authorization), the issued token MUST omit the delegation agent,
task, capabilities, oversight, and audit sections. These sections
describe the agent control plane and leak agent-identifying context
that a non-agent audience does not need for access decisions.
* If the deployment does not advertise delegation_chains, the issued
token MAY omit delegation entirely.
* If the deployment advertises delegation_chains: true, the issued
token MUST retain a projected delegation claim containing only the
lineage needed for depth enforcement and family revocation (depth,
max_depth, chain, parent_jti, root_jti; see Section 7). Previous
audience-specific pairwise values MUST NOT be copied verbatim into
the new audience context and MUST be recomputed per Section 4.3.
Claims that the downstream audience does need (iss, aud, sub,
act.sub, scope, authorization_details, cnf, jti, iat, exp) are copied
or recomputed from the subject token: pairwise identifiers are
recomputed for the target audience (Section 4.3), DPoP binding is
taken from the token exchange request's proof, and
authorization_details is narrowed per the rules below.
8.2. Privilege Reduction
Every token exchange MUST enforce privilege reduction on the issued
token:
* scope MUST be a subset of the subject token's scope.
Valverde Expires 20 October 2026 [Page 28]
Internet-Draft PACT April 2026
* authorization_details MUST be a subset of the subject token's
authorization_details.
* Lifetime MUST NOT exceed the subject token's remaining lifetime.
8.3. Request and Response
A downstream audience MAY negotiate a specialized
requested_token_type (for example, a deployment-specific signed
artifact type). The specific types are out of scope for this
profile; the rules above apply regardless of the chosen type.
Request:
POST {token_endpoint}
DPoP: <proof bound to the caller key>
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=<CIBA access token>
subject_token_type=urn:ietf:params:oauth:token-type:access_token
requested_token_type=
urn:ietf:params:oauth:token-type:access_token
audience=<target RP client_id>
Issued token (illustrative):
{
"iss": "https://as.example.com",
"aud": "<target RP client_id>",
"sub": "<pairwise user id for target RP>",
"act": { "sub": "<pairwise agent id for target RP>" },
"scope": "<narrowed subset>",
"authorization_details": [
{
"type": "purchase",
"merchant": "Acme",
"item": "Widget",
"amount": { "value": "29.99", "currency": "USD" }
}
],
"cnf": { "jkt": "<DPoP key thumbprint>" },
"jti": "<unique>",
"iat": 1711000000,
"exp": 1711003600
}
Valverde Expires 20 October 2026 [Page 29]
Internet-Draft PACT April 2026
The target RP validates the JWT signature against the AS's JWKS,
verifies a matching DPoP proof against cnf.jkt, and enforces the
authorization_details constraints. It does not need to understand
the agent capability model; it only needs to trust the signature and
proof-of-possession binding.
9. Temporal Boundaries
Agent sessions have bounded lifetimes. Expired or terminated
sessions MUST NOT be reactivated.
9.1. Two Independent Clocks
Each agent session has two independent lifetime clocks: one tracks
inactivity, the other tracks total elapsed time since session
creation.
+==========+==============================+==========+=============+
| Clock | Measured from | Default | Purpose |
+==========+==============================+==========+=============+
| Idle TTL | Last activity (last_seen_at) | 1800s | Inactivity |
| | | (30 min) | timeout |
+----------+------------------------------+----------+-------------+
| Max | Session creation | 86400s | Total |
| lifetime | (created_at) | (24 h) | session cap |
+----------+------------------------------+----------+-------------+
Table 13
Lifecycle computation:
1. If persisted status is revoked or expired: keep it (terminal).
2. Compute idle_expires_at = last_seen_at + idle_ttl_sec * 1000.
3. Compute max_expires_at = created_at + max_lifetime_sec * 1000.
4. If now >= idle_expires_at OR now >= max_expires_at: status is
expired.
5. Otherwise: status is active.
Expiry is not only inferred at read time. It MUST be persisted to
the database once observed.
9.2. No Reactivation
Valverde Expires 20 October 2026 [Page 30]
Internet-Draft PACT April 2026
+----------+ +----------+
| active | ---> | expired |
+----+-----+ +----------+
|
v
+----------+
| revoked |
+----------+
There is no reactivation path for sessions. If a session expires,
the client creates a new session under the same host. This is
simpler and more auditable than hidden reactivation logic, and it
ensures that escalated session grants do not survive across
activation boundaries.
9.3. Renewal Through Use
Session activity (last_seen_at) is updated after successful
authenticated operations, specifically after successful Agent-
Assertion binding during CIBA requests. The idle boundary is renewed
by successful use, not by mere existence.
9.4. Revocation Cascade
An agent session can be revoked by the user (via dashboard or API),
the client (via POST {revocation_endpoint} with the bootstrap token
carrying agent:session.revoke), or the server (policy-based).
Revoking a session also revokes all its session grants (status =
"revoked", revoked_at = now). Revoking a host revokes all sessions
under it, cascading to all session grants.
Logout coordination. The authorization server MUST revoke all
pending CIBA requests for a user at the time of user logout (per VEIL
[I-D.valverde-oauth-veil]). A CIBA token MUST NOT be issuable after
the user's session has been terminated. Without this, an agent
polling after user logout could obtain tokens for a session the user
intended to end.
10. Machine-Readable Surfaces
PACT exposes its agent authorization model through four machine-
readable surfaces: an agent configuration document, a capability
registry, token introspection, and an optional A2A agent card.
Valverde Expires 20 October 2026 [Page 31]
Internet-Draft PACT April 2026
10.1. Agent Configuration Document
GET /.well-known/agent-configuration is the profile discovery
endpoint. No authentication required.
{
"issuer": "https://as.example.com",
"registration_endpoint":
"https://as.example.com/api/auth/agent/register",
"host_registration_endpoint":
"https://as.example.com/api/auth/agent/host/register",
"capabilities_endpoint":
"https://as.example.com/api/auth/agent/capabilities",
"introspection_endpoint":
"https://as.example.com/api/auth/agent/introspect",
"revocation_endpoint":
"https://as.example.com/api/auth/agent/revoke",
"jwks_uri": "https://as.example.com/api/auth/agent/jwks",
"supported_algorithms": ["EdDSA"],
"approval_methods": ["ciba"],
"approval_page_url_template":
"https://as.example.com/approve/{auth_req_id}",
"supported_features": {
"task_attestation": true,
"pairwise_agents": true,
"risk_graduated_approval": true,
"capability_constraints": true,
"delegation_chains": false
}
}
The document SHOULD be served with Cache-Control: public, max-
age=3600.
10.2. Capability Discovery
GET {capabilities_endpoint} returns the full capability registry.
GET {capabilities_endpoint}/{name} returns a single capability with
full input/output schemas.
No authentication required for either endpoint.
10.3. Introspection with Lifecycle
POST {introspection_endpoint} follows the [RFC7662] model for agent
token validation.
Valverde Expires 20 October 2026 [Page 32]
Internet-Draft PACT April 2026
Authentication. Requires a client_credentials access token with
agent:introspect scope.
Request: application/x-www-form-urlencoded or application/json with a
token field.
Key behaviors:
* Session lifecycle is re-evaluated at query time. A session that
expired between token issuance and introspection returns active:
false.
* sub and agent.id MUST come from a consistent caller-relative
pairwise view. If the server cannot safely re-project sub for the
introspecting client, it MUST omit sub rather than leak another
client's pairwise identifier.
* client_id and aud continue to identify the token that was issued,
not the introspector's own client registration.
* If assertion_verified is false on the token snapshot, delegation
claims are omitted.
10.4. A2A Agent Card (Informational)
Deployments MAY additionally publish an A2A Protocol [A2A] agent card
at GET /.well-known/agent-card.json that references the agent
configuration document, to support agent-to-agent capability
discovery ecosystems that rely on that surface. This integration is
informational: the A2A Protocol is not a normative dependency of this
profile, and conforming implementations are not required to emit the
A2A card.
11. Cryptographic Continuity
Each phase of the profile produces cryptographic evidence consumed by
the next. A relying party verifies the delegation chain by
inspecting the resulting OAuth messages; each step requires proof
that only the legitimate caller can produce.
11.1. The Full Chain
Valverde Expires 20 October 2026 [Page 33]
Internet-Draft PACT April 2026
+-------------------------------------+
| OAuth User Token |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Durable Host Registration |
| Host Ed25519 key bound to |
| user + client |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Agent Session Registration |
| Fresh Ed25519 key bound to |
| host + runtime |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Agent-Assertion on CIBA |
| Runtime proof bound to specific |
| consent request |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Human Approval via CIBA |
| Consent bound to scope + |
| authorization_details |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Access Token |
| sub + act.sub + PACT delegation |
| claims |
+-----------------+-------------------+
|
v
+-------------------------------------+
| Token Exchange (optional) |
| Audience rebinding + claim |
| narrowing for downstream RP |
+-------------------------------------+
Valverde Expires 20 October 2026 [Page 34]
Internet-Draft PACT April 2026
11.2. Session Binding
The client authenticates with a user-bound OAuth access token,
typically sender-constrained through DPoP. This binds delegated
setup work to the caller's proof-of-possession key.
11.3. Host Binding
Host registration binds a durable Ed25519 public key to one user, one
OAuth client, and one installation thumbprint. The signed host-
attestation+jwt used during session registration proves that the
caller still possesses the durable host private key.
11.4. Runtime Binding
Session registration binds a fresh Ed25519 public key to one host,
one runtime process, and one display metadata snapshot. The Agent-
Assertion proves possession of that runtime key on each CIBA request.
11.5. Consent Binding
CIBA binds human approval to one auth_req_id, one binding message,
one scope set, and one optional authorization_details payload.
If the runtime proof is present and valid, the server snapshots
runtime metadata into the CIBA request before the approval result is
finalized.
11.6. Disclosure Binding
Identity release follows VEIL [I-D.valverde-oauth-veil]: PII is
staged in an ephemeral single-consume store and delivered via the
userinfo endpoint, never embedded in id_token or access-token claims.
PACT sets the CIBA TTL to 10 minutes; the OAuth2 TTL of 5 minutes is
inherited unchanged.
11.7. Delegation Binding
The delegated access token carries sub for the human principal,
act.sub for the acting agent session, and the full PACT delegation
claim set (Section 7). Tokens issued by token exchange to a non-
agent audience carry pairwise sub, pairwise act.sub, cnf.jkt, and the
approved authorization_details, all re-derived or rebound for the
target audience per Section 8.
Valverde Expires 20 October 2026 [Page 35]
Internet-Draft PACT April 2026
12. Security Considerations
Implementations MUST satisfy the security considerations of OAuth 2.1
[I-D.ietf-oauth-v2-1], CIBA [CIBA-Core], OAuth Token Exchange
[RFC8693], and VEIL [I-D.valverde-oauth-veil].
12.1. JTI Replay Protection
All Agent-Assertion JWTs require a jti claim. The server MUST reject
duplicates for the same session and retain seen values until the
assertion's exp plus a clock-skew allowance (SHOULD default to 30
seconds). Cache entries are partitioned by session ID.
12.2. Algorithm Confusion Prevention
JWT verification MUST derive the algorithm from the public key's
curve (Ed25519 -> EdDSA, P-256 -> ES256), never from the JWT alg
header.
12.3. JWKS Fetch Hardening
Remote JWKS URL fetches (for attestation verification) MUST block
private and loopback IP addresses, enforce HTTPS in production, limit
redirects (max 3), cap response size, enforce timeouts, and cache
responses.
12.4. Host Key Security
Host private keys MUST be stored with filesystem permissions
restricting access to the owning user only (mode 0600). The
directory MUST be mode 0700.
12.5. Session Key Ephemerality
Session private keys MUST exist only in process memory. They MUST
NOT be written to disk, environment variables, or any persistent
store.
12.6. Task Description Sensitivity
Task descriptions may contain user-specific context. They appear as
task.purpose in tokens (category-level, not verbatim). The verbatim
description is available only via introspection by authorized machine
clients, not in the JWT body.
Valverde Expires 20 October 2026 [Page 36]
Internet-Draft PACT April 2026
12.7. DPoP Binding
Delegated access tokens issued by this profile SHOULD be DPoP-bound
[RFC9449]. When token exchange mints a downstream token from a CIBA
access token, the issued token MUST carry cnf.jkt from the validated
DPoP proof and the target RP MUST require a matching DPoP proof at
presentation time. A leaked exchanged token is useless without the
caller's proof-of-possession key.
13. Privacy Considerations
The privacy considerations of VEIL [I-D.valverde-oauth-veil] apply in
addition to those below. Participants are the user, the agent
session, the durable host installation, the authorization server, and
the relying parties receiving delegated tokens. Cross-RP correlation
through agent identifiers requires explicit opt-in at registration.
13.1. Cross-RP Agent Correlation
Without pairwise agent identifiers, act.sub in delegated tokens is a
stable correlator across all RPs. Two colluding RPs can link agent
activity across services, correlate the frequency and timing of
operations, and infer usage patterns that may deanonymize the human.
PACT mitigates this by deriving act.sub per-RP using the same sector-
identifier mechanism as OIDC Core pairwise subjects.
13.2. PII in Tokens
Identity PII MUST NOT be embedded in access tokens or purchase
authorization artifacts. PII delivery uses the ephemeral in-memory
store with single-consume semantics. This ensures that long-lived
tokens contain only cryptographic identifiers, not personal data.
13.3. Metadata Minimization
Agent display metadata (model, runtime, version) is informational and
self-declared. It SHOULD NOT be relied upon for security decisions.
Trust decisions MUST be based on cryptographic verification (key
signatures, attestation) rather than declared metadata.
13.4. Pairwise Opt-Out
RPs that require stable agent identifiers (for example, for
regulatory audit trails) opt in through an agent-specific signal
distinct from VEIL's user-facing subject_type. The default is
pairwise.
Valverde Expires 20 October 2026 [Page 37]
Internet-Draft PACT April 2026
14. IANA Considerations
This document requests the registrations listed below. Media types
under application/*+jwt are registered per [RFC7515].
14.1. Media Type Registrations
This document requests two registrations in the "Media Types"
registry under the application/ tree:
* application/agent-assertion+jwt: JWT typ defined in Section 6.3;
used in the Agent-Assertion HTTP header to prove runtime session
identity on CIBA requests.
* application/host-attestation+jwt: JWT typ defined in Section 4.2;
host-signed assertion consumed by the session registration
endpoint.
Each registration specifies this document as its reference and
references [RFC7515] for the +jwt structured syntax suffix semantics.
14.2. Well-Known URI Registration
This document requests one registration in the "Well-Known URIs"
registry [RFC8615]:
* URI suffix: agent-configuration
* Change Controller: IETF
* Reference: This document, Section 10.1
* Status: Permanent
14.3. HTTP Field Name Registrations
This document requests three registrations in the "Hypertext Transfer
Protocol (HTTP) Field Name Registry" [RFC9110]:
* Field Name: Agent-Assertion. Status: permanent. Reference: this
document Section 6.3.
* Field Name: OAuth-Client-Attestation. Status: permanent.
Reference: [I-D.ietf-oauth-attestation-based-client-auth].
* Field Name: OAuth-Client-Attestation-PoP. Status: permanent.
Reference: [I-D.ietf-oauth-attestation-based-client-auth].
Valverde Expires 20 October 2026 [Page 38]
Internet-Draft PACT April 2026
The latter two fields are registered by their originating draft; PACT
references them without redefinition.
14.4. JWT Claim Registrations
This document requests registrations in the "JSON Web Token Claims"
registry [RFC7519] for the delegation claim vocabulary defined in
Section 7:
* agent: Object describing the acting agent runtime and attestation
posture.
* task: Object describing the task category under which delegation
was authorized.
* capabilities: Array of approved named actions with typed
constraint snapshots.
* oversight: Object carrying human-approval requirements and the
originating approval reference.
* audit: Object carrying a CIBA trace identifier and session
reference.
* delegation: Object tracking the delegation chain.
The act, authorization_details, cnf, jti, iat, exp, iss, aud, sub,
and scope claims are referenced as already registered and are used
per their originating specifications ([RFC8693] Section 4.1 for act,
[RFC9396] for authorization_details, [RFC7800] for cnf, [RFC7519] for
the common set).
14.5. OAuth Extensions Error Registry
PACT does not currently request new OAuth error codes; it uses the
step-up error contract inherited from VEIL (interaction_required) and
standard CIBA and token-exchange errors defined in their respective
specifications.
14.6. ACR Values
ACR URNs in acr_values_supported are deployment-local (see VEIL
[I-D.valverde-oauth-veil]). PACT does not register ACR values or
reserve an ACR namespace.
Valverde Expires 20 October 2026 [Page 39]
Internet-Draft PACT April 2026
15. Conformance
15.1. Server Requirements
A conforming authorization server MUST:
* Implement the identity model.
* Compute pairwise agent identifiers by default.
* Implement the capability registry and grant model.
* Route consent based on approval strength.
* Verify Agent-Assertions and bind them to CIBA requests.
* Issue tokens with PACT delegation claims only when assertions are
verified.
* Publish the agent configuration document.
* Enforce JTI replay protection.
* Derive JWT algorithms from public keys, not headers.
A conforming authorization server SHOULD:
* Support vendor attestation.
* Enforce usage limits atomically.
* Support token exchange with claim narrowing for downstream
audiences.
* Provide introspection with lifecycle evaluation.
* Bind tokens with DPoP.
15.2. Client Requirements
A conforming client MUST:
* Generate and persist Ed25519 host keys.
* Generate ephemeral Ed25519 session keys in memory only.
* Sign host-attestation+jwt for session registration.
Valverde Expires 20 October 2026 [Page 40]
Internet-Draft PACT April 2026
* Sign Agent-Assertion JWTs before CIBA requests.
* Include jti in all signed JWTs.
A conforming client SHOULD:
* Present vendor attestation headers when available.
* Request only the capabilities it needs.
* Propose constraints that reflect its actual intended usage.
16. References
16.1. Normative References
[CIBA-Core]
OpenID Foundation, "OpenID Connect Client-Initiated
Backchannel Authentication Core 1.0", n.d.,
<https://openid.net/specs/openid-connect-client-initiated-
backchannel-authentication-core-1_0.html>.
[I-D.ietf-oauth-attestation-based-client-auth]
"OAuth 2.0 Attestation-Based Client Authentication", n.d.,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-
attestation-based-client-auth/>.
[I-D.ietf-oauth-v2-1]
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet-
Draft, draft-ietf-oauth-v2-1-15, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
v2-1-15>.
[OIDC-Core]
OpenID Foundation, "OpenID Connect Core 1.0 incorporating
errata set 2", 15 December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
Valverde Expires 20 October 2026 [Page 41]
Internet-Draft PACT April 2026
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/rfc/rfc7636>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/rfc/rfc7662>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
Valverde Expires 20 October 2026 [Page 42]
Internet-Draft PACT April 2026
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/rfc/rfc9126>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
16.2. Informative References
[A2A] "Agent-to-Agent Protocol", n.d.,
<https://a2a-protocol.org>.
[AAP] "Agent Auth Protocol v1.0-draft", n.d., <https://agent-
auth-protocol.com/specification/v1.0-draft>.
[I-D.aap-oauth-profile]
"Agent Authorization Profile for OAuth", n.d.,
<https://datatracker.ietf.org/doc/draft-aap-oauth-
profile/>.
[I-D.oauth-ai-agents-on-behalf-of-user]
"AI Agents Acting on Behalf of Users", n.d.,
<https://datatracker.ietf.org/doc/draft-oauth-ai-agents-
on-behalf-of-user/>.
[I-D.valverde-oauth-veil]
Valverde, G., "VEIL: Verified Ephemeral Identity Layer for
OAuth 2.1", 2026.
Acknowledgments
The author thanks the OAuth working group and the OpenID Foundation
CIBA editors for ongoing work that this profile composes with, and
the authors of related individual submissions cited in the Relation
to Other Work section for claim-name alignment and shared concepts.
Author's Address
Valverde Expires 20 October 2026 [Page 43]
Internet-Draft PACT April 2026
Gustavo Valverde
Zentity
Portugal
Email: g.valverde02@gmail.com
Valverde Expires 20 October 2026 [Page 44]