Internet Engineering Task Force R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track March 26, 2026 Expires: September 27, 2026 OpenID Connect Agent Identity Claims for Autonomous AI Agents draft-sharif-openid-agent-identity-00 Abstract This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results. 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 September 27, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation and Conventions . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 4. Agent Identity Claims . . . . . . . . . . . . . . . . . . 7 4.1. agent_id . . . . . . . . . . . . . . . . . . . . . . 7 4.2. agent_name . . . . . . . . . . . . . . . . . . . . . 8 4.3. agent_owner . . . . . . . . . . . . . . . . . . . . 9 4.4. agent_trust_score . . . . . . . . . . . . . . . . . 9 4.5. agent_trust_level . . . . . . . . . . . . . . . . . 10 4.6. agent_capabilities . . . . . . . . . . . . . . . . . 12 4.7. agent_sanctions_status . . . . . . . . . . . . . . . 13 4.8. agent_spend_limit . . . . . . . . . . . . . . . . . 14 4.9. agent_attestation_method . . . . . . . . . . . . . . 14 4.10. agent_created_at . . . . . . . . . . . . . . . . . . 15 5. Agent ID Token . . . . . . . . . . . . . . . . . . . . . 16 6. Agent Authentication Flow . . . . . . . . . . . . . . . . 18 6.1. Token Issuance via Client Credentials . . . . . . . 18 6.2. Challenge-Response Extension . . . . . . . . . . . . 20 6.3. Trust Level Requirements per Scope . . . . . . . . . 23 7. Agent Token Validation . . . . . . . . . . . . . . . . . 24 7.1. Standard Validation . . . . . . . . . . . . . . . . 24 7.2. Trust Score Thresholds . . . . . . . . . . . . . . . 26 7.3. Sanctions Status Enforcement . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . 28 8.1. Agent Impersonation . . . . . . . . . . . . . . . . 28 8.2. Trust Score Manipulation . . . . . . . . . . . . . . 29 8.3. Token Replay . . . . . . . . . . . . . . . . . . . . 29 8.4. Sanctions Screening Freshness . . . . . . . . . . . 30 9. Privacy Considerations . . . . . . . . . . . . . . . . . 31 9.1. Agent Identity as PII . . . . . . . . . . . . . . . 31 9.2. Minimal Disclosure . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 10.1. Claims Registration . . . . . . . . . . . . . . . . 33 10.2. OAuth Dynamic Client Registration Metadata Registration . . . . . . . . . . . . . . . . . . . . 35 11. References . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . 38 Appendix B. Document History . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction OpenID Connect Core 1.0 [OpenID.Core] defines an identity layer on top of OAuth 2.0 [RFC6749] that enables Clients to verify the identity of End-Users. The core specification models identity around human subjects: natural persons who authenticate via user agents (typically web browsers) and consent to the release of identity claims to Relying Parties. The emergence of autonomous software agents -- programs that act on behalf of users or organisations to perform tasks, execute transactions, and interact with services without continuous human supervision -- creates a requirement for machine-readable identity that existing OpenID Connect claims do not address. Specifically, current limitations include: o The "sub" claim identifies an End-User, not the autonomous agent acting on their behalf. When multiple agents operate under the same user account, there is no standard mechanism to distinguish between them. o There is no standard claim to express the trust posture of an agent. Relying Parties cannot make graduated access control decisions based on an agent's behavioural history or verification level. o There is no standard claim to express what actions an agent is authorised to perform, distinct from OAuth scopes which express what resources the client application may access. o There is no mechanism for Relying Parties to determine whether an agent or its controlling entity has been screened against sanctions lists, a requirement in regulated financial services. This specification addresses these gaps by defining a profile of OpenID Connect that introduces agent-specific claims carried within standard ID Tokens. The profile is designed with the following principles: 1. Backward compatibility: All defined claims are additional. Existing OpenID Connect deployments that do not recognise agent claims will ignore them per Section 5.1 of [OpenID.Core], which states that Claims not understood MUST be ignored. 2. Separation of concerns: The "sub" claim continues to identify the End-User or organisational entity. The "agent_id" claim identifies the specific agent instance. The "agent_owner" claim links the agent to its controlling subject. 3. Graduated trust: The trust model supports five levels (L0 through L4) that map to progressively wider sets of permitted actions, enabling Relying Parties to implement proportionate access controls. 4. Regulatory alignment: Claims for sanctions screening status and spend limits enable compliance with Anti-Money Laundering (AML) regulations in jurisdictions that require entity screening before financial transactions. This specification is informed by work on agent payment trust frameworks [I-D.sharif-agent-payment-trust], security guidance for Model Context Protocol deployments [I-D.sharif-mcps-secure-mcp], and emerging requirements for autonomous agent identity in financial services. 2. Requirements Notation and 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. In the following text, all references to "Section" without a document identifier refer to sections within this specification. 3. Terminology This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Grant Type", "ID Token", "Refresh Token", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the terms "Claim", "Claim Type", "Claims Provider", "ID Token", "Issuer", and "Relying Party (RP)" defined by OpenID Connect Core 1.0 [OpenID.Core], and the terms "JSON Web Token (JWT)", "Claim Name", "Claim Value", "Header", "Payload", and "Signature" defined by JSON Web Token (JWT) [RFC7519]. This specification also defines the following terms: Agent An autonomous software program that acts on behalf of a user or organisation to perform tasks, execute transactions, or interact with services. An Agent operates with a degree of autonomy and MAY make decisions within the boundaries of its authorised capabilities. Agent Identity Provider (Agent IdP) An OpenID Provider (OP) that issues ID Tokens containing the agent claims defined in this specification. An Agent IdP MAY be the same entity as the user's OpenID Provider or MAY be a separate service specialising in agent identity. Agent Owner The End-User or organisation that deployed and controls the Agent. The Agent Owner is identified by the "agent_owner" claim and is responsible for the Agent's actions. Trust Score A numerical representation of an Agent's behavioural trustworthiness, expressed as an integer in the range [0, 100]. Trust Scores are computed by the Agent IdP based on criteria including transaction history, attestation strength, and compliance screening results. Trust Level A graduated classification of an Agent's trust posture, expressed as one of five levels (L0 through L4). Trust Levels determine the maximum scope of actions an Agent is permitted to perform at a given Relying Party. 4. Agent Identity Claims This section defines the claims that represent agent identity within an OpenID Connect ID Token. These claims are carried in the ID Token payload alongside standard OpenID Connect claims. All claims defined in this section use the "agent_" prefix to avoid collision with existing OpenID Connect claims and to enable Relying Parties to identify agent-specific assertions unambiguously. The following table summarises the agent claims: +-----------------------------+----------+----------+ | Claim | Type | Required | +-----------------------------+----------+----------+ | agent_id | string | REQUIRED | | agent_name | string | OPTIONAL | | agent_owner | string | REQUIRED | | agent_trust_score | integer | OPTIONAL | | agent_trust_level | string | OPTIONAL | | agent_capabilities | array | OPTIONAL | | agent_sanctions_status | string | OPTIONAL | | agent_spend_limit | integer | OPTIONAL | | agent_attestation_method | string | OPTIONAL | | agent_created_at | integer | OPTIONAL | +-----------------------------+----------+----------+ Table 1: Agent Identity Claims 4.1. agent_id Claim Name: agent_id Claim Description: A globally unique identifier for the Agent. Claim Type: String Requirement Level: REQUIRED The value MUST be a non-empty string of no more than 255 characters. The value MUST be unique within the namespace of the issuing Agent IdP. To achieve global uniqueness across IdPs, implementations SHOULD use one of the following formats: o A UUID v4 as defined in [RFC4122], e.g., "550e8400-e29b-41d4-a716-446655440000" o A URN using a domain-scoped identifier, e.g., "urn:example.com:agent:payment-bot-001" o A domain-qualified identifier using the dot-separated convention, e.g., "payment-bot.example.com" The Agent IdP MUST NOT reuse an "agent_id" value for a different agent instance. Once assigned, an "agent_id" MUST remain stable for the lifetime of the agent. Example: "agent_id": "payment-bot.cybersecai.co.uk" 4.2. agent_name Claim Name: agent_name Claim Description: A human-readable display name for the Agent. Claim Type: String Requirement Level: OPTIONAL The value MUST be a non-empty string of no more than 128 characters when present. The value is intended for display purposes in administrative interfaces and audit logs. Relying Parties MUST NOT use the "agent_name" for identification or access control decisions; the "agent_id" claim MUST be used for that purpose. Example: "agent_name": "Payment Processing Agent" 4.3. agent_owner Claim Name: agent_owner Claim Description: The subject identifier of the entity that deployed and controls the Agent. Claim Type: String Requirement Level: REQUIRED The value MUST be the "sub" claim value of the Agent Owner as issued by the same Agent IdP, or a URI that resolves to the owner's identity record at the Agent IdP. This establishes a verifiable chain of accountability from the Agent to its controlling entity. When the Agent IdP is the same OpenID Provider that issued the owner's identity, the value MUST be identical to the "sub" claim in the owner's own ID Token. When the Agent IdP is a separate service, the value SHOULD be a URI of the form: https://{owner-idp}/.well-known/openid-configuration #sub={value} Relying Parties MUST verify that the "agent_owner" value corresponds to a valid, active subject at the referenced identity provider before granting access to protected resources. Example: "agent_owner": "user_2fK9xLm3nP7qR8s" 4.4. agent_trust_score Claim Name: agent_trust_score Claim Description: A numerical trust score representing the Agent's behavioural trustworthiness. Claim Type: Integer Requirement Level: OPTIONAL The value MUST be an integer in the range [0, 100] inclusive. A value of 0 indicates no established trust. A value of 100 indicates the highest level of trust. The methodology for computing trust scores is not defined by this specification and is at the discretion of the Agent IdP. However, the Agent IdP SHOULD document its trust score computation methodology in its OpenID Provider metadata or in a referenced policy document. Factors that MAY influence the trust score include: o Duration and consistency of agent operation o Transaction completion rate and dispute history o Strength of the attestation method used o Sanctions screening result o Compliance with rate limits and usage policies Example: "agent_trust_score": 72 4.5. agent_trust_level Claim Name: agent_trust_level Claim Description: A graduated trust classification for the Agent. Claim Type: String Requirement Level: OPTIONAL The value MUST be one of the following enumerated strings: +-------+------------------+------------------------------------+ | Level | Label | Description | +-------+------------------+------------------------------------+ | "L0" | Unverified | No identity verification | | | | performed. Agent MAY only access | | | | public resources. | +-------+------------------+------------------------------------+ | "L1" | Basic | API key or shared secret | | | | attestation. Agent MAY perform | | | | read operations. | +-------+------------------+------------------------------------+ | "L2" | Verified | Certificate or JWT-based | | | | attestation. Agent MAY perform | | | | write operations within defined | | | | limits. | +-------+------------------+------------------------------------+ | "L3" | Trusted | Challenge-response attestation | | | | with cryptographic proof. Agent | | | | MAY perform financial transactions | | | | within spend limits. | +-------+------------------+------------------------------------+ | "L4" | High Assurance | Multi-factor attestation including | | | | hardware-bound keys. Agent MAY | | | | perform high-value transactions. | +-------+------------------+------------------------------------+ Table 2: Agent Trust Levels When both "agent_trust_score" and "agent_trust_level" are present, the "agent_trust_level" MUST be consistent with the "agent_trust_score". The following mapping defines the minimum trust score for each level: L0: score < 20 L1: 20 <= score < 40 L2: 40 <= score < 60 L3: 60 <= score < 80 L4: score >= 80 If the values are inconsistent, the Relying Party MUST reject the token. Example: "agent_trust_level": "L3" 4.6. agent_capabilities Claim Name: agent_capabilities Claim Description: The set of actions the Agent is authorised to perform. Claim Type: JSON array of strings Requirement Level: OPTIONAL Each element of the array MUST be a non-empty string that identifies a specific capability. Capability identifiers SHOULD use the dot-separated hierarchical naming convention: {domain}.{resource}.{action} Relying Parties MUST treat the "agent_capabilities" claim as the maximum set of actions the Agent is authorised to perform. A Relying Party MAY further restrict the effective capabilities based on its own policies, the Agent's trust level, or other contextual factors. The "agent_capabilities" claim is distinct from OAuth 2.0 scopes. Scopes define what resources the client application may access at the authorisation server level. Agent capabilities define what actions the specific Agent instance is permitted to perform at the application level. Example: "agent_capabilities": [ "payments.transfer.initiate", "payments.balance.read", "reporting.transactions.export" ] 4.7. agent_sanctions_status Claim Name: agent_sanctions_status Claim Description: The result of sanctions screening performed on the Agent and/or its owner. Claim Type: String Requirement Level: OPTIONAL The value MUST be one of the following enumerated strings: +----------------+----------------------------------------------+ | Value | Description | +----------------+----------------------------------------------+ | "CLEAR" | The Agent and its owner have been screened | | | against applicable sanctions lists and no | | | matches were found. | +----------------+----------------------------------------------+ | "HIT" | The screening process identified a potential | | | match against one or more sanctions lists. | | | The Agent MUST NOT be permitted to perform | | | financial transactions until the match is | | | resolved. | +----------------+----------------------------------------------+ | "NOT_SCREENED" | No sanctions screening has been performed. | +----------------+----------------------------------------------+ Table 3: Sanctions Status Values When the value is "HIT", the Agent IdP SHOULD include additional context in a separate claims source or via a UserInfo endpoint response. This specification does not define the format of additional sanctions screening details. The Agent IdP MUST record the date and time of the most recent screening. Relying Parties operating in regulated environments SHOULD verify that the screening was performed within a timeframe acceptable to their compliance policies (see Section 8.4). Example: "agent_sanctions_status": "CLEAR" 4.8. agent_spend_limit Claim Name: agent_spend_limit Claim Description: The maximum transaction amount the Agent is authorised to initiate in a single transaction. Claim Type: Integer Requirement Level: OPTIONAL The value MUST be a non-negative integer representing the amount in minor currency units (e.g., pence for GBP, cents for USD). A value of 0 indicates that the Agent is not authorised to initiate financial transactions. The currency is not encoded in this claim. The applicable currency MUST be determined from context, such as the Relying Party's configuration or an associated claim in the ID Token. If the currency is ambiguous, the Relying Party MUST reject financial transaction requests. Example (representing GBP 250.00): "agent_spend_limit": 25000 4.9. agent_attestation_method Claim Name: agent_attestation_method Claim Description: The method by which the Agent's identity was verified by the Agent IdP. Claim Type: String Requirement Level: OPTIONAL The value MUST be one of the following enumerated strings: +----------------------+----------------------------------------+ | Value | Description | +----------------------+----------------------------------------+ | "challenge_response" | Identity verified via a cryptographic | | | challenge-response protocol (see | | | Section 6.2). | +----------------------+----------------------------------------+ | "certificate" | Identity verified via a valid X.509 | | | certificate presented during TLS | | | client authentication or at the | | | application layer. | +----------------------+----------------------------------------+ | "jwt" | Identity verified via a signed JWT | | | presented as a client assertion per | | | [RFC7523]. | +----------------------+----------------------------------------+ | "api_key" | Identity verified via a pre-shared | | | API key. | +----------------------+----------------------------------------+ Table 4: Attestation Method Values The attestation method informs Relying Parties of the strength of the identity verification. Relying Parties SHOULD require "challenge_response" or "certificate" attestation for agents performing high-value or sensitive operations. Example: "agent_attestation_method": "challenge_response" 4.10. agent_created_at Claim Name: agent_created_at Claim Description: The time at which the Agent was created or registered with the Agent IdP. Claim Type: Integer Requirement Level: OPTIONAL The value MUST be a NumericDate as defined in Section 2 of [RFC7519], representing the number of seconds from 1970-01-01T00:00:00Z UTC to the agent creation time. Relying Parties MAY use this claim in conjunction with the trust score to assess whether a newly created agent with an unexpectedly high trust score warrants additional scrutiny. Example (representing 2026-01-15T09:30:00Z): "agent_created_at": 1768561800 5. Agent ID Token The Agent ID Token is a standard OpenID Connect ID Token [OpenID.Core] Section 2 that includes the agent claims defined in Section 4 of this specification. The Agent ID Token MUST conform to all requirements of an ID Token as defined in Section 2 of [OpenID.Core]. In particular: o The token MUST be a JWT [RFC7519] signed using JWS [RFC7515]. o The "iss" claim MUST contain the Issuer Identifier of the Agent IdP. o The "sub" claim MUST contain a subject identifier. When the Agent acts on behalf of a user, the "sub" claim SHOULD contain the user's subject identifier. When the Agent acts on behalf of an organisation without a specific user context, the "sub" claim SHOULD contain an organisational identifier. o The "aud" claim MUST contain the client_id of the Relying Party. o The "iat" and "exp" claims MUST be present. o The token MUST contain at minimum the "agent_id" and "agent_owner" claims defined in this specification. The following is a non-normative example of an Agent ID Token payload: { "iss": "https://idp.example.com", "sub": "org_8kP2mN5xQ9", "aud": "client_rp_payments_001", "exp": 1768565400, "iat": 1768561800, "nonce": "n-0S6_WzA2Mj", "agent_id": "payment-bot.example.com", "agent_name": "Payment Processing Agent", "agent_owner": "org_8kP2mN5xQ9", "agent_trust_score": 72, "agent_trust_level": "L3", "agent_capabilities": [ "payments.transfer.initiate", "payments.balance.read", "reporting.transactions.export" ], "agent_sanctions_status": "CLEAR", "agent_spend_limit": 25000, "agent_attestation_method": "challenge_response", "agent_created_at": 1768561800 } The following is the corresponding JOSE Header: { "alg": "RS256", "typ": "JWT", "kid": "2026-03-key-01" } Agent claims MAY also be returned from the UserInfo Endpoint as defined in Section 5.3 of [OpenID.Core]. When agent claims are requested via the UserInfo Endpoint, the same claim names and semantics defined in Section 4 apply. When an Agent IdP supports agent claims, it SHOULD advertise this capability in its OpenID Provider Metadata [OpenID.Discovery] by including the following metadata parameter: "agent_claims_supported": true The Agent IdP SHOULD also list the supported agent claims in the "claims_supported" metadata parameter: "claims_supported": [ "sub", "name", "email", "agent_id", "agent_name", "agent_owner", "agent_trust_score", "agent_trust_level", "agent_capabilities", "agent_sanctions_status", "agent_spend_limit", "agent_attestation_method", "agent_created_at" ] 6. Agent Authentication Flow This section defines how an Agent IdP issues tokens for Agents and how Agents authenticate to Relying Parties. 6.1. Token Issuance via Client Credentials Agent authentication uses the OAuth 2.0 Client Credentials grant type [RFC6749] Section 4.4, extended with agent claim parameters. The Agent or its controlling software sends a token request to the Agent IdP's Token Endpoint. The request MUST include the following parameters: grant_type REQUIRED. Value MUST be "client_credentials". client_id REQUIRED. The client identifier issued to the Agent or its controlling application by the Agent IdP. client_secret or client_assertion REQUIRED. Client authentication as defined in Section 2.3 of [RFC6749] or Section 2.2 of [RFC7523]. scope OPTIONAL. The requested scope. To request agent claims in the resulting token, the scope MUST include "openid" and SHOULD include "agent_identity". agent_id REQUIRED. The identifier of the Agent for which the token is being requested. The following is a non-normative example of a token request: POST /token HTTP/1.1 Host: idp.example.com Content-Type: application/x-www-form-urlencoded grant_type=client_credentials &client_id=agent_controller_001 &client_secret=s3cr3t &scope=openid%20agent_identity%20payments.transfer &agent_id=payment-bot.example.com If the request is valid and the client is authorised to request tokens for the specified agent, the Agent IdP responds with a token response as defined in Section 4.4.3 of [RFC6749], with the addition of an "id_token" parameter containing the Agent ID Token: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6ImF0K...", "token_type": "Bearer", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIs..." } The Agent IdP MUST verify the following before issuing the token: 1. The client is authenticated and authorised to request tokens for the specified "agent_id". 2. The specified Agent exists and is in an active state. 3. The Agent's trust score, trust level, and sanctions status are current. 4. The requested scopes are within the Agent's authorised capabilities. 6.2. Challenge-Response Extension For high-assurance agent verification (trust level L3 and above), this specification defines a challenge-response extension that provides cryptographic proof of agent identity. The flow consists of two exchanges: Step 1: Challenge Request The Agent requests a challenge from the Agent IdP: POST /agent/challenge HTTP/1.1 Host: idp.example.com Content-Type: application/json { "agent_id": "payment-bot.example.com", "client_id": "agent_controller_001" } The Agent IdP responds with a challenge: HTTP/1.1 200 OK Content-Type: application/json { "challenge": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk", "challenge_id": "ch_9xK2mN5pQ7rS", "expires_in": 300 } The "challenge" value MUST be a cryptographically random string of at least 32 bytes, Base64url-encoded without padding. The Agent IdP MUST store the challenge and associate it with the specified "agent_id" and "client_id". The challenge MUST expire after the number of seconds indicated by "expires_in", which MUST NOT exceed 600 seconds. Step 2: Challenge Response The Agent signs the challenge using its private key and submits the response as part of the token request: POST /token HTTP/1.1 Host: idp.example.com Content-Type: application/x-www-form-urlencoded grant_type=client_credentials &client_id=agent_controller_001 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A client-assertion-type%3Ajwt-bearer &client_assertion=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9... &scope=openid%20agent_identity &agent_id=payment-bot.example.com &challenge_id=ch_9xK2mN5pQ7rS &challenge_response=MEUCIQDf1... The "challenge_response" value MUST be the digital signature of the "challenge" value, computed using the Agent's private key and encoded as Base64url without padding. The Agent IdP MUST verify: 1. The "challenge_id" corresponds to a valid, unexpired challenge issued to the specified "agent_id" and "client_id". 2. The "challenge_response" is a valid signature of the original challenge value, verified using the Agent's registered public key. 3. The challenge has not been previously used (one-time use). Upon successful verification, the Agent IdP issues a token with "agent_attestation_method" set to "challenge_response" and "agent_trust_level" of at least "L3". The following is a non-normative example of the signed challenge JWT payload (used in client_assertion): { "iss": "agent_controller_001", "sub": "payment-bot.example.com", "aud": "https://idp.example.com/token", "jti": "ch_9xK2mN5pQ7rS", "challenge": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk", "iat": 1768561800, "exp": 1768562100 } 6.3. Trust Level Requirements per Scope Relying Parties SHOULD define minimum trust level requirements for each action scope they support. The following table provides a non-normative example of scope-to-trust-level mappings: +------------------------------+----------+-------------------+ | Scope | Min | Min Attestation | | | Trust | Method | | | Level | | +------------------------------+----------+-------------------+ | data.public.read | L0 | any | +------------------------------+----------+-------------------+ | data.private.read | L1 | api_key | +------------------------------+----------+-------------------+ | data.private.write | L2 | jwt | +------------------------------+----------+-------------------+ | payments.transfer.initiate | L3 | challenge_ | | | | response | +------------------------------+----------+-------------------+ | payments.high_value.initiate | L4 | certificate | +------------------------------+----------+-------------------+ Table 5: Scope to Trust Level Mapping When an Agent presents a token with a trust level below the minimum required for the requested action, the Relying Party MUST reject the request with an HTTP 403 response and SHOULD include an error response body indicating the required trust level: HTTP/1.1 403 Forbidden Content-Type: application/json { "error": "insufficient_trust_level", "error_description": "This action requires agent_trust_level L3 or above. The presented token contains trust level L1.", "required_trust_level": "L3", "current_trust_level": "L1" } 7. Agent Token Validation This section defines how Relying Parties validate Agent ID Tokens. 7.1. Standard Validation Relying Parties MUST perform all validation steps defined in Section 3.1.3.7 of [OpenID.Core] for ID Token validation. In addition, the following agent-specific validation steps MUST be performed: 1. Verify that the "agent_id" claim is present and is a non-empty string of no more than 255 characters. 2. Verify that the "agent_owner" claim is present and is a non-empty string. 3. If the "agent_trust_score" claim is present, verify that it is an integer in the range [0, 100]. 4. If the "agent_trust_level" claim is present, verify that it is one of the values defined in Table 2. 5. If both "agent_trust_score" and "agent_trust_level" are present, verify that they are consistent per the mapping defined in Section 4.5. If they are inconsistent, the token MUST be rejected. 6. If the "agent_capabilities" claim is present, verify that it is a JSON array of non-empty strings. 7. If the "agent_sanctions_status" claim is present, verify that it is one of the values defined in Table 3. 8. If the "agent_spend_limit" claim is present, verify that it is a non-negative integer. 9. If the "agent_attestation_method" claim is present, verify that it is one of the values defined in Table 4. 10. If the "agent_created_at" claim is present, verify that it is a valid NumericDate and that it is not in the future. If any of the above validation steps fail, the Relying Party MUST reject the token and MUST NOT grant access to protected resources. 7.2. Trust Score Thresholds Relying Parties that implement graduated access controls based on trust scores SHOULD define threshold values for each category of protected resource. The following is a non-normative example of threshold-based access control logic: function evaluateAccess(token, requestedAction) { // Reject if sanctions status is HIT if (token.agent_sanctions_status === "HIT") { return { allowed: false, reason: "sanctions_hit" }; } // Determine required trust score for the action const thresholds = { "read": 20, "write": 40, "transfer": 60, "admin": 80 }; const requiredScore = thresholds[requestedAction.category]; if (requiredScore === undefined) { return { allowed: false, reason: "unknown_action" }; } if ((token.agent_trust_score || 0) < requiredScore) { return { allowed: false, reason: "insufficient_trust_score", required: requiredScore, actual: token.agent_trust_score || 0 }; } return { allowed: true }; } Relying Parties SHOULD log all access decisions, including the agent_id, requested action, trust score, and decision outcome, for audit purposes. 7.3. Sanctions Status Enforcement Relying Parties operating in regulated financial services jurisdictions MUST enforce sanctions status as follows: 1. If the "agent_sanctions_status" claim is "HIT", the Relying Party MUST deny all financial transaction requests from the Agent. The Relying Party MAY permit non-financial read-only access at its discretion. 2. If the "agent_sanctions_status" claim is "NOT_SCREENED" and the Relying Party requires sanctions screening, the Relying Party MUST deny financial transaction requests and SHOULD return an error indicating that screening is required: HTTP/1.1 403 Forbidden Content-Type: application/json { "error": "sanctions_screening_required", "error_description": "Agent sanctions screening has not been performed. Financial transactions require a CLEAR sanctions status." } 3. If the "agent_sanctions_status" claim is absent, the Relying Party MUST treat it as equivalent to "NOT_SCREENED" when sanctions screening is required by regulation or policy. 8. Security Considerations 8.1. Agent Impersonation An attacker who obtains an Agent's client credentials can request tokens on behalf of the Agent. To mitigate this risk: o Agent IdPs SHOULD require challenge-response attestation (Section 6.2) for Agents operating at trust level L3 or above. o Agent private keys used for challenge-response SHOULD be stored in hardware security modules (HSMs) or trusted execution environments (TEEs). o Agent IdPs SHOULD implement anomaly detection to identify token requests from unexpected network locations or at unusual times. o Relying Parties SHOULD implement request-level anomaly detection in addition to token validation. 8.2. Trust Score Manipulation Trust scores are asserted by the Agent IdP and are only as reliable as the IdP's computation methodology and integrity. o Relying Parties MUST NOT accept trust scores from Agent IdPs that they have not explicitly trusted. o Agent IdPs MUST protect trust score computation systems from tampering. Trust score updates SHOULD require multi-party authorisation for changes exceeding a defined threshold (e.g., an increase of more than 20 points in a single update). o Agent IdPs SHOULD implement rate limiting on trust score increases to prevent rapid escalation attacks. o Relying Parties MAY implement their own supplementary trust scoring that combines the Agent IdP's score with locally observed agent behaviour. 8.3. Token Replay Agent ID Tokens are bearer tokens and are susceptible to replay attacks if intercepted. o Agent ID Tokens SHOULD have short expiration times. An expiration time ("exp") of no more than 3600 seconds after issuance ("iat") is RECOMMENDED for general use. For financial transactions, an expiration time of no more than 300 seconds is RECOMMENDED. o Relying Parties SHOULD implement token binding or sender- constrained tokens as defined in [RFC9449] (DPoP) to prevent token replay by parties other than the intended agent. o When the nonce claim is present, Relying Parties MUST verify that the nonce has not been previously used within the token's validity period. 8.4. Sanctions Screening Freshness Sanctions lists are updated periodically. A sanctions screening result that was valid at the time of screening may become stale. o Agent IdPs SHOULD re-screen Agents and their owners at regular intervals. A re-screening interval of no more than 24 hours is RECOMMENDED for Agents performing financial transactions. o Agent IdPs SHOULD include a "screened_at" claim (NumericDate) in the ID Token or make it available via the UserInfo Endpoint, indicating when the most recent screening was performed. o Relying Parties in regulated environments SHOULD reject tokens where the sanctions screening is older than their compliance policy permits. A maximum staleness of 24 hours is RECOMMENDED for PSD2-regulated services. 9. Privacy Considerations 9.1. Agent Identity as PII When an Agent acts on behalf of a specific End-User, the combination of "agent_id" and "agent_owner" can constitute Personally Identifiable Information (PII) as defined in applicable data protection regulations, including the UK GDPR and EU GDPR. o Agent IdPs MUST process agent identity data in accordance with applicable data protection regulations. o When an Agent acts on behalf of a natural person, the Agent Owner MUST have provided informed consent for the Agent IdP to disclose their subject identifier in the "agent_owner" claim. o Relying Parties MUST NOT retain agent identity claims beyond the period necessary for the purpose for which they were collected, subject to regulatory retention requirements. o Agent IdPs SHOULD support pairwise subject identifiers as defined in Section 8 of [OpenID.Core] for the "agent_owner" claim to limit cross-Relying Party correlation of Agent Owners. 9.2. Minimal Disclosure Agent IdPs and Relying Parties SHOULD implement the principle of minimal disclosure: o Agent IdPs SHOULD issue tokens containing only the agent claims requested by the Relying Party and necessary for the intended transaction. o Relying Parties SHOULD request only the agent claims necessary for their access control decisions. o The "agent_trust_score" claim provides finer-grained information than "agent_trust_level". When the Relying Party's access control decisions are based solely on trust levels, the "agent_trust_score" SHOULD be omitted to reduce information disclosure. o The "agent_capabilities" claim SHOULD be filtered to include only capabilities relevant to the Relying Party, rather than the complete set of the Agent's capabilities. 10. IANA Considerations 10.1. Claims Registration This specification registers the following claims in the IANA "JSON Web Token Claims" registry established by [RFC7519]: Claim Name: agent_id Claim Description: Unique identifier for an autonomous software agent Change Controller: IESG Specification Document(s): Section 4.1 of this specification Claim Name: agent_name Claim Description: Human-readable display name for an agent Change Controller: IESG Specification Document(s): Section 4.2 of this specification Claim Name: agent_owner Claim Description: Subject identifier of the entity controlling the agent Change Controller: IESG Specification Document(s): Section 4.3 of this specification Claim Name: agent_trust_score Claim Description: Numerical trust score for agent behavioural trustworthiness Change Controller: IESG Specification Document(s): Section 4.4 of this specification Claim Name: agent_trust_level Claim Description: Graduated trust classification for an agent Change Controller: IESG Specification Document(s): Section 4.5 of this specification Claim Name: agent_capabilities Claim Description: Set of actions an agent is authorised to perform Change Controller: IESG Specification Document(s): Section 4.6 of this specification Claim Name: agent_sanctions_status Claim Description: Result of sanctions screening on an agent or its owner Change Controller: IESG Specification Document(s): Section 4.7 of this specification Claim Name: agent_spend_limit Claim Description: Maximum single transaction amount for an agent in minor currency units Change Controller: IESG Specification Document(s): Section 4.8 of this specification Claim Name: agent_attestation_method Claim Description: Method used to verify agent identity Change Controller: IESG Specification Document(s): Section 4.9 of this specification Claim Name: agent_created_at Claim Description: Unix timestamp of agent creation or registration Change Controller: IESG Specification Document(s): Section 4.10 of this specification 10.2. OAuth Dynamic Client Registration Metadata Registration This specification registers the following client metadata parameter in the IANA "OAuth Dynamic Client Registration Metadata" registry: Client Metadata Name: agent_claims_supported Client Metadata Description: Boolean indicating whether the OpenID Provider supports issuing agent identity claims Change Controller: IESG Specification Document(s): Section 5 of this specification 11. References 11.1. Normative References [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", December 2023, . [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 11.2. Informative References [I-D.sharif-agent-payment-trust] Sharif, R., "Agent Payment Trust Framework", Internet-Draft draft-sharif-agent-payment-trust-00, March 2026, . [I-D.sharif-mcps-secure-mcp] Sharif, R., "MCPS: Secure Model Context Protocol", Internet-Draft draft-sharif-mcps-secure-mcp-00, March 2026, . [OWASP.MCP] OWASP Foundation, "MCP Security Cheat Sheet", 2026, . [NIST.AI.Agent] National Institute of Standards and Technology, "NCCoE AI Agent Identity Concept Paper", 2026, . Appendix A. Acknowledgements The author gratefully acknowledges the contributions of the OpenID Foundation AI Identity Management Community Group members whose review and feedback shaped this specification. This work builds on the agent payment trust framework described in [I-D.sharif-agent-payment-trust] and incorporates security considerations from the OWASP MCP Security Cheat Sheet [OWASP.MCP] Section 7, and security guidance for MCP deployments from [I-D.sharif-mcps-secure-mcp]. Appendix B. Document History draft-sharif-openid-agent-identity-00 -- March 2026 o Initial draft. o Defined ten agent identity claims with full type definitions and validation rules. o Specified Agent ID Token structure and Agent IdP metadata. o Defined client credentials flow with challenge-response extension. o Defined trust level requirements per action scope. o Defined token validation procedures including trust score thresholds and sanctions enforcement. Author's Address Raza Sharif CyberSecAI Ltd London, United Kingdom Email: contact@agentsign.dev URI: https://cybersecai.co.uk