]> Grantex

mishra.sanjeev@gmail.com https://grantex.dev

Security Web Authorization Protocol AI agents authorization OAuth delegation JWT grant token Artificial intelligence (AI) agents increasingly take autonomous actions — submitting forms, initiating payments, and sending communications — on behalf of human users across third-party services. This document defines the Delegated Agent Authorization Protocol (DAAP), an open, model-neutral, framework-agnostic protocol that specifies: cryptographic agent identity using Decentralized Identifiers (DIDs); a human-consent-based grant authorization flow modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token format with agent-specific claims; a revocation model with online verification; a hash-chained append-only audit trail; a policy engine for automated authorization decisions; and a multi-agent delegation model with cascade revocation. DAAP fills a gap unaddressed by existing OAuth 2.0 extensions: verifying that a specific human authorized a specific AI agent to perform a specific action, revoking that authorization in real time, and producing a tamper-evident record of what the agent did.

Introduction Deployed AI agents operate across arbitrary third-party services using credentials and permissions that belong to the human users they serve. Today, no interoperable standard exists for:

1. Verifying that an agent is who it claims to be
2. Confirming that a specific human authorized a specific agent to perform a specific action
3. Revoking that authorization in real time across all active tokens
4. Producing a tamper-evident record of agent activity

OAuth 2.0 and its extensions address authorization for applications acting on behalf of users, but were not designed for the AI agent use case, which introduces distinct requirements:

• Agent identity: Unlike OAuth clients, AI agents are runtime entities that may be spawned dynamically and must carry a persistent cryptographic identity independent of the authorization server.
• Multi-agent delegation: An agent may spawn sub-agents, each of which requires a grant scoped to a subset of the parent's permissions, with the entire delegation tree revocable by the original principal.
• Tamper-evident audit trail: Regulated environments require a cryptographically linked record of agent activity that is verifiable without trust in the audit log operator.
• Policy-driven automation: High-volume agent deployments require automated authorization decisions (auto-approve, auto-deny) without per-request human interaction, while preserving the human principal's ability to revoke at any time.

DAAP addresses these requirements as a layered extension to OAuth 2.0 concepts, reusing RFC-standard JWT and JWK primitives wherever possible.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used throughout this document:

Agent:

An AI-powered software process that takes autonomous actions on behalf of a Principal. An Agent has a persistent cryptographic identity (DID) and must obtain an explicit grant from its Principal before acting on their behalf.

Principal:

The human user who authorizes an Agent to act on their behalf. The Principal is the subject (sub) of any Grant Token issued by the authorization server.

Developer:

The organization or individual who built and operates the Agent. The Developer authenticates to the authorization server using an API key.

Authorization Server:

A server implementing this specification that issues Grant Tokens, maintains the grant registry, and provides the JWKS endpoint for offline verification.

Service:

Any API or platform that receives requests from an Agent. Services MUST verify Grant Tokens before acting on agent requests.

Grant:

A persistent record of permission given by a Principal to an Agent for a specific set of Scopes. A Grant is represented to the Agent as a Grant Token.

Grant Token:

A signed JWT representing a valid, non-revoked Grant. Grant Tokens are short-lived credentials carrying agent-specific claims defined in .

Scope:

A named permission string following the format resource:action[:constraint] as defined in .

DID:

A Decentralized Identifier — the Agent's cryptographic identity. In DAAP, Agent DIDs take the form did:grantex:<agent_id>.

Policy:

A rule evaluated by the Policy Engine () that automatically approves or denies an authorization request before the consent UI is shown to the Principal.

Anomaly:

A behavioral deviation from an agent's established activity baseline, detected by the runtime monitoring system defined in .

Agent Identity

DID Format Every Agent registered with a DAAP-compliant Authorization Server receives a Decentralized Identifier of the form: ]]> where <agent_id> is a ULID (Universally Unique Lexicographically Sortable Identifier) prefixed with ag_. Example:

Identity Document The DID resolves to an identity document at the Authorization Server. The document MUST contain the following fields:

Key Management Authorization Servers MUST adhere to the following key management requirements:

• Authorization Servers MUST use RS256 (RSASSA-PKCS1-v1_5 using SHA-256) for signing Grant Tokens.
• Private signing keys MUST never be transmitted or stored outside the Authorization Server's trust boundary.
• Public keys MUST be published at /.well-known/jwks.json as a JWK Set .
• Key rotation MUST be supported without changing the Agent's DID or invalidating existing, unexpired Grant Tokens. Rotated keys MUST remain in the JWKS until all tokens signed with them have expired.

Scope Format and Registry

Format Scopes are permission strings of the form: where:

• resource identifies the data or service being accessed (e.g., calendar, payments, email)
• action identifies the operation (e.g., read, write, send, initiate, delete)
• constraint is an optional limiting parameter (e.g., max_500 for a spending limit)

Standard Scope Registry The following scopes constitute the normative standard registry. Implementations MUST support all standard scopes that are relevant to the resources they expose:

Scope	Description
calendar:read	Read calendar events
calendar:write	Create, modify, and delete calendar events
email:read	Read email messages
email:send	Send emails on the Principal's behalf
email:delete	Delete email messages
files:read	Read files and documents
files:write	Create and modify files
payments:read	View payment history and balances
payments:initiate	Initiate payments of any amount
payments:initiate:max_N	Initiate payments up to N in the account's base currency
profile:read	Read profile and identity information
contacts:read	Read address book and contacts

Custom Scopes Services MAY define custom scopes using reverse-domain notation per : Custom scopes MUST use reverse-domain notation to avoid collisions with the standard registry.

Scope Display Requirements Authorization Servers MUST maintain a human-readable description for each scope in their registry. Consent UIs MUST display human-readable descriptions to Principals, never raw scope strings.

Grant Authorization Flow

Overview The DAAP grant flow is modelled on the OAuth 2.0 Authorization Code flow with the following adaptations: the client is always a Developer (identified by an API key), the resource owner is a Principal identified by the Developer's internal user identifier, and the resulting token carries agent-specific claims. | | | | | |<------------------------| | | {authRequestId, | | | consentUrl} | | | | | | redirect user --------------------------------->| | | consent UI displayed | | |<---------------------| | | Principal approves | | | | |<------------------------------------------------| | redirectUri?code=AUTH_CODE | | | | | POST /v1/token | | | {code, agentId} | | |------------------------>| | |<------------------------| | | {grantToken, | | | refreshToken} | | ]]>

Authorization Request The Developer initiates the flow by sending: Content-Type: application/json { "agentId": "ag_01HXYZ123abc", "principalId": "user_abc123", "scopes": ["calendar:read", "payments:initiate:max_500"], "expiresIn": "24h", "redirectUri": "https://yourapp.com/auth/callback", "state": "", "audience": "https://api.targetservice.com" } ]]> The audience field is OPTIONAL. When present, it MUST be embedded as the aud claim in the issued Grant Token. The state parameter is REQUIRED and MUST be validated by the Developer's callback handler to prevent CSRF attacks. The redirectUri MUST match a URI pre-registered for the Agent at the Authorization Server. Authorization Servers MUST reject requests whose redirectUri does not exactly match a pre-registered value for the specified agentId. Response 200 OK:

Consent UI Requirements Authorization Servers MUST render a consent UI to the Principal that displays all of the following before the Principal approves or denies:

1. The Agent's registered name and description
2. The Developer's registered organization name
3. The full list of requested scopes with human-readable descriptions
4. The token expiry period
5. A prominent deny/cancel action that is at least as visually prominent as the approve action

Token Exchange After Principal approval, the Authorization Server calls redirectUri?code=AUTH_CODE&state=STATE. Content-Type: application/json { "code": "AUTH_CODE", "agentId": "ag_01HXYZ123abc" } ]]> Response 200 OK: Refresh tokens are single-use. The Authorization Server MUST rotate the refresh token on every use. Refresh tokens MUST be invalidated when the underlying Grant is revoked.

Grant Token Format

JOSE Header " } ]]> The alg field MUST be RS256. Authorization Servers MUST NOT issue tokens with any other algorithm. Verifiers MUST explicitly reject tokens with any alg value other than RS256, including none and HS256.

JWT Claims The following claims are defined by this specification:

Claim	Type	Required	Description
iss	string	REQUIRED	Authorization Server identifier URI
sub	string	REQUIRED	Principal identifier
aud	string	OPTIONAL	Intended audience (target service URI)
agt	string	REQUIRED	Agent DID
dev	string	REQUIRED	Developer organization identifier
grnt	string	REQUIRED	Grant identifier (used for revocation lookup)
scp	string[]	REQUIRED	Array of granted scope strings
iat	NumericDate	REQUIRED	Issued-at time
exp	NumericDate	REQUIRED	Expiration time
jti	string	REQUIRED	Unique token identifier (for replay prevention)

Token Validation Services receiving a Grant Token MUST verify all of the following:

1. The token signature is valid, verified using the JWK Set published at {iss}/.well-known/jwks.json, with the key identified by kid.
2. The alg header value is RS256. Tokens with any other alg MUST be rejected.
3. The exp claim has not passed (allowing for a reasonable clock skew of no more than 300 seconds).
4. If the service has a registered audience identifier, the aud claim matches that identifier.
5. The scp array contains all scopes required for the requested operation.
6. For high-stakes operations (see ), the token has not been revoked via the online verification endpoint.

Token Lifetime Guidance

Use Case	Recommended Maximum TTL
High-stakes actions (payments:initiate, email:send, files:write)	1 hour
Standard agent tasks	8 hours
Long-running background agents	24 hours

Implementations caching revocation state MUST NOT cache for longer than 300 seconds (5 minutes). Services processing high-stakes scopes (payments:initiate, email:send, files:write) SHOULD perform online verification for each token use.

Token Revocation

Revoke a Grant ]]> Effect: all active Grant Tokens issued under this Grant are immediately invalidated. The Grant record is marked revoked with a timestamp.

Revoke a Specific Token Content-Type: application/json { "jti": "tok_01HXYZ987xyz" } ]]> Response: 204 No Content.

Online Verification Content-Type: application/json { "token": "eyJhbGciOiJSUzI1NiJ9..." } ]]> Response 200 OK:

JTI Replay Prevention Authorization Servers MUST track all issued jti values for the lifetime of the corresponding token. If a jti value is presented for verification more than once within its validity window, the Authorization Server MUST return valid: false and SHOULD log an anomaly event.

Audit Trail

Log Entry Schema action values use the format resource.verb (e.g., payment.initiated, email.sent). status MUST be one of success, failure, or blocked.

Hash Chain Each entry's hash is computed as a SHA-256 digest over a canonical representation of the entry: where canonical_json serializes all fields as a JSON object with keys sorted alphabetically, and prevHash is the null string for the first entry in a chain. This construction makes any retrospective modification to a historical entry detectable, as it invalidates all subsequent hashes.

Audit Log Requirements

• Audit log entries MUST be append-only at the API level. No update or delete endpoints for audit entries are permitted.
• The Authorization Server MUST reject requests to modify or delete audit entries.
• The complete audit log for a Grant MUST remain accessible after the Grant is revoked, for a minimum retention period determined by the deployment's compliance requirements.

Multi-Agent Delegation

Delegation Token Claims When Agent A spawns Agent B, B's Grant Token MUST carry delegation claims linking it to the original Principal's authorization: Additional delegation claims:

Claim	Type	Description
parentAgt	string	DID of the delegating (parent) Agent
parentGrnt	string	Grant ID of the parent Grant
delegationDepth	integer	Number of hops from the root Grant; 0 for root Grants

Delegation Rules

• Sub-agent scopes MUST be a strict subset of the parent Grant's scp array. Authorization Servers MUST reject delegation requests whose requested scopes are not fully contained in the parent token's scp claim.
• delegationDepth MUST be incremented by exactly 1 at each hop.
• Implementations MUST enforce a developer-configurable delegation depth limit. The RECOMMENDED default limit is 3. Implementations MUST enforce a hard cap of 10 regardless of developer configuration.
• The expiry of a delegated Grant Token MUST NOT exceed min(parent_token_exp, now + requested_expires_in).

Delegation Endpoint Content-Type: application/json { "parentGrantToken": "eyJhbGciOiJSUzI1NiJ9...", "subAgentId": "ag_01HXYZ_sub", "scopes": ["email:read"], "expiresIn": "1h" } ]]> The Authorization Server MUST:

1. Validate that the parent Grant has not been revoked.
2. Reject with 400 if any requested scope is not present in the parent token's scp claim.
3. Reject with 400 if the resulting delegationDepth would exceed the configured limit.
4. Reject with 404 if subAgentId does not belong to the authenticated Developer.
5. Compute expiry as min(parent token exp, now + expiresIn).

Response 201 Created:

Cascade Revocation Revoking a Grant via DELETE /v1/grants/:id MUST atomically revoke all descendant Grants — that is, all Grants whose parent_grant_id traces back to the revoked Grant at any depth. Authorization Servers SHOULD implement this as a single recursive database transaction to eliminate any window during which descendant tokens remain valid.

Conformance Requirements A conformant DAAP Authorization Server MUST expose the following endpoints:

Endpoint	Description
POST /v1/agents	Register an Agent
POST /v1/authorize	Initiate the grant authorization flow
POST /v1/token	Exchange authorization code for Grant Token
POST /v1/tokens/verify	Online token verification
POST /v1/tokens/revoke	Revoke a specific token by JTI
GET /v1/grants	List a Principal's active Grants
GET /v1/grants/:id	Retrieve a single Grant
DELETE /v1/grants/:id	Revoke a Grant (cascades to all descendants)
POST /v1/grants/delegate	Issue a delegated sub-agent Grant
POST /v1/audit/log	Write an audit log entry
GET /v1/audit/entries	Query the audit log
GET /v1/audit/:id	Retrieve a single audit log entry
GET /.well-known/jwks.json	JWK Set for offline token verification
GET /health	Health check

The following endpoints are OPTIONAL. Implementations that choose to support an optional extension MUST implement it as specified in this document:

• Policy Engine: POST /v1/policies, GET /v1/policies, GET /v1/policies/:id, PATCH /v1/policies/:id, DELETE /v1/policies/:id
• Webhooks: POST /v1/webhooks, GET /v1/webhooks, DELETE /v1/webhooks/:id
• Anomaly Detection: POST /v1/anomalies/detect, GET /v1/anomalies, PATCH /v1/anomalies/:id/acknowledge
• Enterprise SCIM 2.0: /scim/v2/ endpoints as defined in RFC 7642/7643/7644
• SSO (OIDC): POST /v1/sso/config, GET /sso/login, GET /sso/callback

Policy Engine

Purpose The Policy Engine evaluates developer-defined rules against each authorization request before the consent UI is displayed. Policies enable developers to auto-approve routine low-risk requests and auto-deny requests that violate organizational constraints.

Effects

Effect	Description
auto_approve	Grant Token issued immediately without showing the consent UI
auto_deny	Authorization request rejected immediately with 403 Forbidden

Condition Fields

Field	Type	Description
scopes	string[]	Matches when the requested scopes are a subset of this list
principalId	string	Matches a specific Principal identifier
agentId	string	Matches a specific Agent identifier
timeWindow	object	Time constraint: { "startHour": N, "endHour": N, "days": [1..7] } where days are ISO weekday integers (1=Monday, 7=Sunday)

Evaluation Order Policy evaluation MUST follow this order:

1. auto_deny rules are evaluated first. The first matching deny rule wins and the request is rejected immediately.
2. auto_approve rules are evaluated next. The first matching allow rule causes the Grant Token to be issued.
3. If no rule matches, the consent UI is displayed to the Principal.

This ordering ensures that restrictive policies cannot be bypassed by a conflicting allow rule.

Anomaly Detection

Purpose The anomaly detection system monitors Agent behavior at runtime against each Agent's established activity baseline. It identifies behavioral deviations and surfaces them to Developers for review.

Non-Blocking Requirement Anomaly detection MUST NOT block token issuance. Detection operates asynchronously as an advisory layer. Authorization Servers MUST NOT delay Grant Token responses pending anomaly analysis.

Anomaly Types

Type	Description
unusual_scope_access	Agent requested scopes outside its established pattern
high_frequency	Token issuance rate significantly exceeds the agent's baseline
off_hours_activity	Activity detected outside the Principal's normal active hours
new_principal	Agent is requesting access for a previously unserved Principal
cascade_delegation	Delegation chain depth approaching or exceeding configured limits

Severity Levels Anomaly severity MUST be one of: low, medium, high, critical.

Security Considerations

Algorithm Restrictions All Grant Tokens MUST be signed with RS256 (RSASSA-PKCS1-v1_5 with SHA-256). Symmetric signing algorithms, including HS256, are NOT PERMITTED. All verifiers MUST explicitly reject tokens presenting alg: none or any symmetric algorithm, regardless of library defaults. This prevents algorithm confusion attacks as described in . RSA key moduli MUST be at least 2048 bits. Authorization Servers generating or importing signing keys MUST enforce this minimum.

Token Replay Prevention Every issued Grant Token carries a unique jti claim. Authorization Servers providing online verification MUST track issued jti values and reject any verification request presenting a jti that has already been used, for the full lifetime of the token.

CSRF and Redirect URI Security The state parameter in the authorization request MUST be a cryptographically random, unpredictable value generated per-request. Developer callback handlers MUST validate the returned state value against the value sent in the original request. Redirect URIs MUST be pre-registered by the Developer for each Agent. Authorization Servers MUST perform exact-match comparison of the redirectUri in each authorization request against the pre-registered set. Prefix matching and wildcard matching are NOT PERMITTED.

Scope Reduction for Delegation Delegated Grant Tokens MUST carry a scope set that is a strict subset of the parent Grant's scope set. Authorization Servers MUST enforce this at token issuance time; it MUST NOT be enforced only at verification time.

Revocation Propagation Authorization Servers MUST propagate grant revocation to all descendant grants atomically. The maximum allowable latency between a revocation request and the invalidation of all descendant tokens via the online verification endpoint is implementation-defined, but implementations SHOULD target sub-second propagation. Implementations caching revocation state MUST NOT cache for longer than 300 seconds.

Consent UI Integrity Consent UIs MUST display the agent name, developer name, all requested scopes with human-readable descriptions, token expiry, and a prominent deny/cancel action. This information MUST be sourced from the Authorization Server's registry, not from the authorization request itself, to prevent a malicious Developer from displaying misleading scope descriptions.

Audit Log Integrity The hash-chain construction defined in ensures that any modification to a historical audit entry is detectable. Implementations MUST store audit log entries in an append-only manner and MUST expose no API for modification or deletion of audit entries. Audit log export implementations SHOULD verify the hash chain before serving exports.

Enterprise Identity Security SSO callback handlers MUST validate both the state (CSRF protection) and nonce (replay protection) parameters before establishing a session. ID tokens received in the SSO callback MUST be cryptographically verified against the identity provider's JWKS endpoint before any claims are trusted. SCIM provisioning endpoints MUST authenticate via a credential (SCIM Bearer token) that is entirely separate from the Developer API key infrastructure. Compromise of a Developer API key MUST NOT grant access to SCIM provisioning endpoints, and vice versa.

IANA Considerations

JWT Claims Registration This document requests registration of the following claims in the IANA "JSON Web Token Claims" registry established by :

agt:

Claim Name: agt

Claim Description: Agent Decentralized Identifier

Change Controller: IETF

Specification Document: This document,

dev:

Claim Name: dev

Claim Description: Developer organization identifier

Change Controller: IETF

Specification Document: This document,

grnt:

Claim Name: grnt

Claim Description: Grant identifier for revocation lookup

Change Controller: IETF

Specification Document: This document,

scp:

Claim Name: scp

Claim Description: Array of granted authorization scope strings

Change Controller: IETF

Specification Document: This document,

parentAgt:

Claim Name: parentAgt

Claim Description: DID of the delegating parent Agent

Change Controller: IETF

Specification Document: This document,

parentGrnt:

Claim Name: parentGrnt

Claim Description: Grant identifier of the parent Grant

Change Controller: IETF

Specification Document: This document,

delegationDepth:

Claim Name: delegationDepth

Claim Description: Number of delegation hops from the root Grant

Change Controller: IETF

Specification Document: This document,

Well-Known URI Registration No new Well-Known URIs are defined by this specification. Implementations use the existing /.well-known/jwks.json path established by .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Informative References This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. W3C

Comparison with OAuth 2.0 Extensions DAAP shares OAuth 2.0's fundamental grant model but differs in the following respects: versus RFC 6749 (OAuth 2.0): OAuth 2.0 defines a general-purpose delegated authorization framework. DAAP specializes this for AI agents by: adding cryptographic agent identity (DID); defining agent-specific JWT claims (agt, dev, grnt, scp); mandating RS256 exclusively; and adding the delegation, audit, policy, and anomaly detection subsystems. versus RFC 8693 (Token Exchange): Token Exchange enables a client to exchange one token for another, including impersonation and delegation use cases. DAAP's delegation model serves a narrower purpose — chaining AI agent sub-authorizations back to a human principal — and adds depth-limiting and cascade revocation semantics not present in RFC 8693. versus RFC 7662 (Token Introspection): Token Introspection defines an endpoint for resource servers to query token metadata. DAAP's /v1/tokens/verify endpoint serves a similar purpose but returns DAAP-specific fields (agent, principal, scopes) and is used by agent-side SDKs rather than resource servers.

Acknowledgements The authors thank the members of the IETF OAuth Working Group for prior art in delegated authorization, and the W3C Decentralized Identifier Working Group for the DID specification that DAAP builds upon for agent identity.