Delegated Identity

Draft. This section is a working draft, published for comment. Its MUST and SHOULD language states what the working group intends, but it is not yet a conformance requirement, and it may change incompatibly before it is. Do not claim conformance with it. If you build against it, tell the working group what broke: that is the evidence that moves a draft.

This section is written in domain-neutral terms. It describes principals, agents and servers rather than shoppers, assistants and dealerships, because the problem is not specific to retail automotive. Automotive appears only in the examples.

It profiles the 2026-07-28 revision of the Model Context Protocol. It builds on MCP authorization (OAuth 2.1, Protected Resource Metadata, Client ID Metadata Documents, resource indicators, scope challenges and step-up) and on the single-server profile of §6, and adds what neither defines: what a token issued to an agent acting for a person must say, and what a server must do with it. It is published as the candidate extension io.automotivemcp/agent-identity.

12.1 The problem

The reference flow reaches step 5 and stops: the person decides to book, so identity is now required. Steps 5, 6, 7, 10 and 11 all ask one question from different sides: who is acting, for whom, and on what authority?

Today there are two answers, and both are wrong for agents:

• The person signs in at every business. That is what MCP's authorization flow does, and it is correct for one server. An agent that compares five businesses cannot send its user through five sign-up forms, and a person who has never dealt with a business has no account there to sign in to.
• The agent holds a broad credential. It calls everything as itself. The server then cannot tell which person a call is for, cannot limit what the agent does to what that person allowed, and cannot show anyone afterwards who authorized what.

MCP's Enterprise-Managed Authorization extension solves a neighbouring case, an employee's agent inside a company that runs its own identity provider. It does not cover a person acting for themselves with an agent from a provider of their choosing, at a business they have no prior relationship with. That case is this section.

12.2 Roles

The server's question is never only "is this a valid token?" It is "which operator's agent, acting for which principal, allowed to do what, and since when?" A token issued under this section MUST let the server answer all four.

12.3 Agent identity

An agent is an OAuth client, and this profile identifies it the way MCP prefers: by a Client ID Metadata Document, so that the client_id is an https URL the operator controls.

• An agent acting under this section MUST use a Client ID Metadata Document client_id. The origin of that URL identifies the operator.
• The metadata document MUST name the operator, a contact for abuse reports, and the policy under which the operator verifies principals (§12.4). The fields are listed in §12.9.
• An operator that runs many agent instances MAY identify an instance in the act claim (§12.5), but the server's trust decision is about the operator, not the instance.
• Tokens issued to an agent SHOULD be sender-constrained (DPoP, RFC 9449), so that a token copied out of an agent's logs is not usable by anyone else. Bearer tokens remain permitted while this section is a draft.

A server decides for itself which operators it serves. This section does not create a list of approved operators, and a server MUST NOT be required to accept an operator it has no basis to trust.

12.4 Principal identity

12.4.1 Levels

A server needs different assurance for different actions. Reading public inventory needs none. Booking an appointment needs a reachable contact point. A credit application needs the regulated identity checks of its domain. This profile names the levels so that a tool can state what it requires and a token can state what it carries:

A tool that requires a level above anonymous MUST say which, in the tool's annotations, so that an agent can know before calling it.

12.4.2 Proving control of a contact point

contact_verified is the level step 6 of the reference flow needs, and it is reached in one of two ways:

1. Verified by the server. The server sends a one-time code to the contact point and asks for it back. Under MCP 2026-07-28 the server does this inside the tool call, by returning an InputRequiredResult carrying an elicitation request, which the agent presents to the principal before retrying the call. The code MUST be single-use, short-lived, and bound to the call that requested it.
2. Attested by the operator. The operator has already verified the contact point and asserts it in the delegation grant (§12.5.2). A server MUST NOT treat an operator's attestation as verification unless it trusts that operator's verification policy, and SHOULD record which operator attested.

The contact point itself is personal data and is governed by §6.3. A server MUST NOT require a contact point for an action whose level is anonymous.

12.5 Delegation

A delegation is the principal's permission for one agent to act at one server, within stated limits. Every token issued under this section represents exactly one delegation.

12.5.1 What the token must carry

Whatever its format, a delegated access token MUST convey these, and a server MUST be able to read them (from a JWT, or from token introspection):

A server MUST reject a token that carries a sub but no act. A token with a principal and no agent is not a delegation; it is a principal's own session, presented by something that is not the principal.

12.5.2 Obtaining a delegation

There are two ways, and the second is the reason this section exists.

Interactive, at the server. The agent runs MCP's authorization code flow with PKCE against the server's authorization server, and the principal approves the delegation there. This works today, needs nothing new, and SHOULD be used wherever the principal can be present at the server once.

By grant, from the operator. The principal approves the delegation once, at their operator. The operator then issues a delegation grant: a signed JWT, audience the server's authorization server, that the agent presents as an RFC 7523 JWT bearer grant (urn:ietf:params:oauth:grant-type:jwt-bearer) together with the resource of the server it wants a token for. The grant carries:

• iss, the operator; aud, the server's authorization server; sub, a pairwise principal identifier for that server
• act, the agent's client_id
• the requested scopes, locations and, for one transaction, authorization_details
• the identity level established, and for contact_verified, the verified contact point, the method, and when it was verified (§12.4.2)
• a short expiry and a jti, so that a grant can be used once

This is deliberately the same shape as MCP's Enterprise-Managed Authorization extension, which has a client obtain a signed identity assertion from an enterprise identity provider and present it as a JWT bearer grant. Here the operator stands where the enterprise identity provider stands. The server's authorization server stays in control: it decides, by its own policy, whether it trusts the operator, whether the requested scopes are acceptable for that operator and that identity level, and what token, if any, to issue.

A server's authorization server:

• MUST reject a grant whose aud is not itself, or whose jti it has seen.
• MUST NOT issue scopes broader than the grant requested, and MAY issue narrower ones.
• MUST NOT accept a grant from an operator it does not trust, and SHOULD say which operators it trusts in its metadata (§12.9).

12.5.3 Chains

An agent may hand part of a task to another agent. That is a chain, and it is recorded, never hidden: the token the second agent uses MUST nest the first agent in its act claim. A delegation MUST NOT grant more than the delegation it came from. A server MAY refuse chains longer than it is willing to audit, and SHOULD refuse any chain it cannot record in full (§12.8).

Federation (§11.8) produces chains of the same shape, with a federating server as an actor.

12.6 Step-up

Some actions need more than the delegation the agent holds: a regulated decision (§6.3), a payment, anything the principal would expect to confirm personally. Step 10 of the reference flow is this case.

• A server that needs more scope MUST use MCP's scope challenge: 403 Forbidden with WWW-Authenticate: Bearer error="insufficient_scope", naming every scope the operation needs in one challenge.
• A server that needs the principal to be present, or a higher identity level, MUST say so in the same challenge, using acr_values and max_age as in the OAuth step-up authentication challenge (RFC 9470), with the levels of §12.4.1 as acr values.
• A step-up that requires the principal MUST be satisfied by the principal. An agent MUST NOT satisfy it on its own, and an operator MUST NOT issue a delegation grant that claims principal presence the principal did not give. A server SHOULD require the interactive flow of §12.5.2 for any step-up to identity_proofed.

12.7 Revocation

A principal MUST be able to withdraw a delegation, and the withdrawal MUST take effect without the agent's cooperation.

• A principal can revoke at the operator, which stops issuing grants, and at the server, which stops honoring tokens. A server SHOULD offer the principal a way to see and revoke the delegations it holds for them, keyed by operator.
• Delegated access tokens SHOULD be short-lived, so that revocation at the operator takes effect within one token lifetime even where the server is never told. A refresh token issued under a delegation MUST be invalidated when the delegation is revoked.
• A server that learns a delegation is revoked MUST stop acting on it within one hour, the same window §9.6 sets for consent, and MUST NOT complete an action the principal has not yet confirmed.
• Revoking a delegation revokes every chain and every federated exchange derived from it. A token obtained by exchange (§11.8) MUST NOT outlive the token it was exchanged from.

12.8 The audit record

Step 11 of the reference flow asks for an exchange that is auditable. A server MUST record an audit event for every call under a delegation that changes state, reads data covered by §6.3, or was preceded by a step-up. The record:

The record exists to answer one question years later: who told the system to do this, through whom, and what were they allowed to do at the time? Retention follows the operator's compliance obligations, and MUST be at least as long as §9.9 requires where a consent receipt is involved. A principal SHOULD be able to obtain the records about themselves.

12.9 Declaring support

A server that supports this section declares it in discovery, and its authorization server publishes the matching metadata:

{
  "extensions": {
    "io.automotivemcp/agent-identity": {
      "version": "0.1-draft",
      "levels": ["anonymous", "contact_verified", "account_linked"],
      "delegation_grant": true,
      "trusted_operators": "https://auth.example-dms.com/operators.json"
    }
  }
}

An agent's Client ID Metadata Document adds, beyond the fields MCP requires:

12.10 Privacy considerations

• Pairwise subjects (§12.5.1) are what stops a principal's agent from becoming a tracking identifier shared by every business it touches. A server MUST NOT ask an operator for a principal identifier that is the same at other servers.
• Minimum disclosure. A delegation grant MUST carry only what the requested level needs. A contact_verified grant carries one contact point, not a profile.
• The operator sees the pattern. An operator issuing grants learns which businesses its users deal with. That is inherent in the design, and operators SHOULD state what they retain.
• Contacting the principal after a delegated interaction is governed by consent (§9), not by the delegation. Permission for an agent to book an appointment is not permission for the business to market to the person.

12.11 Open questions

• Who decides which operators are trustworthy? Each server deciding alone does not scale for small businesses; any shared list concentrates power. A trust framework with published verification policies is one middle path. This is open for a decision by the project owner and working group.
• Is the operator the right party to attest a contact point? It is convenient, and it makes the operator a target. Server-side verification (§12.4.2, method 1) avoids that at the cost of a round trip to the person.
• One-time codes and agents with inbox access. An agent that can read the principal's email or messages can complete a server's verification without the principal. Whether that matters, and what would prevent it, is open.
• Format of the delegation grant. A JWT bearer grant mirrors MCP's enterprise extension and existing OAuth deployments. A verifiable credential with selective disclosure would reveal less, at a cost in implementation effort that §9.13 already weighs for consent receipts.
• Should a consent receipt be bindable to an agent? §9.13 asks the same question from the other side.
• Is one hour fast enough for revocation? As for consent (§9.13), immediate is right and one hour is what batch systems can meet.