Web Authorization Protocol S. Kumar Internet-Draft Orchestrum Technologies LLP Intended status: Informational 30 August 2026 Expires: 3 March 2027 OAuth Profile for Delegated AI Agent Authorization draft-mishra-oauth-agent-grants-02 Abstract AI agents increasingly invoke protected APIs on behalf of human users. This document defines an OAuth profile for identifying an agent client instance, obtaining an authenticated user's consent, issuing resource-bound and sender-constrained access tokens, attenuating authority through OAuth Token Exchange, and rotating refresh tokens safely. The profile uses existing OAuth and JOSE mechanisms wherever possible and defines no new JWT claims or OAuth endpoints. Operational facilities such as policy engines, audit stores, budgets, event streams, and credential vaults are outside the interoperable core. Grantex is an incomplete reference implementation and is not required for conformance. 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 3 March 2027. 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. Kumar Expires 3 March 2027 [Page 1] Internet-Draft DAAP August 2026 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 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Discussion Venues . . . . . . . . . . . . . . . . . . . . 3 1.3. Changes Since -01 . . . . . . . . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Security Model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Agent Client Registration . . . . . . . . . . . . . . . . . . 6 3.1. Optional DID Association . . . . . . . . . . . . . . . . 6 4. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Pushed Authorization Request . . . . . . . . . . . . . . 6 4.2. Principal Interaction . . . . . . . . . . . . . . . . . . 7 4.3. Authorization Code Exchange . . . . . . . . . . . . . . . 8 5. Access Tokens . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 9 6. Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Lost-Response Recovery . . . . . . . . . . . . . . . . . 10 8. Operational Extensions . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9.1. Consent Substitution . . . . . . . . . . . . . . . . . . 12 9.2. Redirect and Authorization Request Integrity . . . . . . 12 9.3. Audience and Sender Binding . . . . . . . . . . . . . . . 12 9.4. Agent-Key Enrollment . . . . . . . . . . . . . . . . . . 13 9.5. Delegation . . . . . . . . . . . . . . . . . . . . . . . 13 9.6. Refresh Reuse . . . . . . . . . . . . . . . . . . . . . . 13 9.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. Relationship to Other Work . . . . . . . . . . . . . . . . . 14 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Non-Normative Grantex Mapping . . . . . . . . . . . 18 Appendix B. Candidate Extension Documents . . . . . . . . . . . 19 Appendix C. Author's Address . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Kumar Expires 3 March 2027 [Page 2] Internet-Draft DAAP August 2026 1. Introduction OAuth deployments already support software acting for users. AI agent deployments add operational pressure because agent instances can be created dynamically, can call high-impact APIs, and can delegate work to other agent instances. These characteristics do not justify replacing OAuth. They do justify a strict profile that removes unsafe choices and makes the acting client, user, resource, and sender key explicit. This document profiles OAuth 2.0 [RFC6749] and the OAuth 2.0 Security Best Current Practice [RFC9700]. It uses pushed authorization requests (PAR) [RFC9126], Proof Key for Code Exchange (PKCE) [RFC7636], resource indicators [RFC8707], JWT access tokens [RFC9068], sender constraints, and OAuth Token Exchange [RFC8693]. The term "DAAP" is a convenient name for this profile. It is not a new authorization framework, a new credential format, or a claim that an AI agent is a legal person. 1.1. Scope This document specifies: 1. security metadata associated with an agent's OAuth client registration; 2. an authorization-code flow with authenticated human consent; 3. resource-bound, sender-constrained JWT access tokens; 4. attenuated delegation using OAuth Token Exchange; and 5. refresh-token rotation requirements, including bounded recovery from a lost successful response. This document does not standardize agent orchestration, model selection, policy languages, payments, budget ledgers, audit storage APIs, event delivery, credential vaults, SCIM, SSO configuration, or vendor deployment endpoints. Those features can be useful, but they require separate specifications and security analysis. 1.2. Discussion Venues Discussion of this document is intended for the OAuth Working Group mailing list at oauth@ietf.org. The archive is at https://mailarchive.ietf.org/arch/browse/oauth/. Kumar Expires 3 March 2027 [Page 3] Internet-Draft DAAP August 2026 Author contact: * Primary: mishra.sanjeev@gmail.com * Alternate: sanjeev@orchestrum.in Source and issue tracking are maintained at https://github.com/mishrasanjeev/grantex/tree/main/docs/ietf-draft. 1.3. Changes Since -01 Revision -02: * narrows the document to an OAuth profile and removes proprietary Grantex endpoint paths from the normative protocol; * requires authenticated human consent and prohibits policy automation from impersonating that consent; * requires exact redirect URI matching, state, PKCE S256, PAR, and a resource indicator; * requires sender-constrained access and refresh tokens; * uses the standard scope, client_id, cnf, and act claims rather than registering duplicate short claims; * defines safety properties for bounded lost-response refresh recovery; * makes DID use optional and requires proof of possession for any advertised agent key; * moves audit, budget, policy, events, and credential-vault behavior outside the interoperable core; and * reports the Grantex implementation as partial rather than conformant. 1.4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Kumar Expires 3 March 2027 [Page 4] Internet-Draft DAAP August 2026 1.5. Terminology This document uses the OAuth roles defined by [RFC6749] and the following terms: Agent: Software that plans or performs actions. An Agent is not itself an OAuth role. Agent Client Instance: An OAuth client instance that executes agent software. Its OAuth client_id identifies its registration, not a human or legal identity. Principal: The human resource owner whose authority is delegated. A deployment can use a non-human resource owner only when its trust and authorization model is defined outside this profile. Agent Key: An asymmetric key controlled by the Agent Client Instance and used for DPoP or mutual-TLS sender constraint. Delegated Token: An access token issued by OAuth Token Exchange whose authority is derived from another token and attenuated in scope, resource, lifetime, or all three. 2. Security Model The authorization server is trusted to authenticate the Principal, display an accurate authorization request, enforce registered client metadata, issue tokens, and process revocation. A resource server is trusted to validate tokens and enforce scopes for its own resource identifier. An Agent Client Instance is not trusted merely because a developer registered it or supplied an API key. Developer authentication and Principal authentication are separate security events. A developer credential MUST NOT be accepted as proof that the Principal approved a live authorization request. For a live authorization, the authorization server MUST authenticate the Principal using a method appropriate to the risk of the requested authority. Phishing-resistant authentication is RECOMMENDED for high-impact scopes. Sandbox deployments MAY use test principals and simulated consent when they are clearly isolated from production resources and credentials. An automated policy decision MAY deny, narrow, or require escalation of a request. It MUST NOT replace the Principal's authenticated approval unless a separate, explicitly authorized non-human resource- owner model applies. Kumar Expires 3 March 2027 [Page 5] Internet-Draft DAAP August 2026 3. Agent Client Registration An Agent Client Instance uses an OAuth client registration. Registration can be provisioned administratively or by a standards- based dynamic registration mechanism; the registration wire protocol is outside this document. The registration MUST bind: * one or more exact redirect URIs for authorization-code clients; * the resources the client is permitted to request; * the scopes the client is permitted to request; and * key metadata sufficient to sender-constrain tokens. The authorization server MUST reject redirect URIs containing fragments and MUST apply the redirect URI rules from [RFC9700]. Production web redirect URIs MUST use HTTPS, except for loopback redirects explicitly permitted for native applications. The Agent Key MUST be asymmetric. The registration MUST NOT contain private key parameters. Before treating a key as controlled by an Agent Client Instance, the authorization server MUST verify possession through DPoP [RFC9449], mutual TLS [RFC8705], or another protocol that proves possession of the corresponding private key. 3.1. Optional DID Association A deployment MAY associate an Agent Client Instance with a DID [DID-CORE]. DID support is not required by this profile. If a DID is placed in a token or shown to a Principal, it MUST resolve to a document that contains the verified Agent Key or a verifiable delegation to that key. An opaque database identifier with a did: prefix is not sufficient. Key rotation MUST preserve an auditable relationship between the old and new keys, invalidate future use of the retired key, and avoid silently changing the meaning of already-issued sender-constrained tokens. 4. Authorization 4.1. Pushed Authorization Request Clients conforming to this profile MUST use PAR [RFC9126]. The pushed request MUST contain, at minimum: Kumar Expires 3 March 2027 [Page 6] Internet-Draft DAAP August 2026 * client_id; * response_type=code; * an exact registered redirect_uri; * scope; * a high-entropy state value; * code_challenge and code_challenge_method=S256; and * exactly one resource value identifying the target resource server. The authorization server MUST reject an unregistered redirect URI, a resource outside the client's registration, or a scope outside the client's registered scope set. It MUST NOT apply prefix, wildcard, or substring matching to a redirect URI. The client then sends the returned request_uri to the authorization endpoint as defined by [RFC9126]. The authorization endpoint MUST reject a request URI that is expired, already consumed where single use is enforced, issued to a different client, or altered. 4.2. Principal Interaction The authorization server MUST authenticate the Principal independently of the developer or Agent Client Instance. The consent view MUST show, in language the Principal can understand: * the Agent Client Instance and responsible developer; * the target resource; * the requested scopes and their consequences; * the requested duration; and * material delegation or transaction constraints. Approval and denial MUST both be bound to the authenticated Principal and the specific authorization request. The authorization server MUST prevent login CSRF, consent CSRF, clickjacking, and reuse of approval artifacts. The client MUST verify that the returned state exactly matches its stored value before exchanging the authorization code. Kumar Expires 3 March 2027 [Page 7] Internet-Draft DAAP August 2026 4.3. Authorization Code Exchange The client exchanges the authorization code at the OAuth token endpoint using grant_type=authorization_code, the code, the same redirect_uri, and the PKCE code_verifier. The authorization server MUST: 1. authenticate or otherwise identify the client as required for its client type; 2. require exact redirect_uri equality with the authorization request; 3. validate the S256 verifier; 4. bind the code to the client, Principal, resource, and approved scopes; and 5. consume the code atomically with successful token issuance. An error while signing or storing tokens MUST leave the authorization code usable for a later retry or MUST produce an unambiguous terminal error. It MUST NOT create a partially committed grant. 5. Access Tokens Authorization servers conforming to this profile issue JWT access tokens [RFC7519] as profiled by [RFC9068]. The JWK Set requirements of [RFC7517], the JOSE requirements of [RFC7518], JWT validation guidance in [RFC8725], and authorization-server metadata in [RFC8414] apply. The authorization server metadata MUST publish a jwks_uri. A JWKS document alone is not authorization-server metadata and MUST NOT be described as conformance with [RFC8414]. 5.1. Claims The token MUST contain the claims required by [RFC9068], including iss, sub, aud, exp, iat, jti, and client_id. Granted scopes MUST use the standard space-delimited scope claim. aud MUST identify the single resource requested during authorization. Tokens without the expected audience MUST be rejected by the resource server. The token MUST be sender-constrained: Kumar Expires 3 March 2027 [Page 8] Internet-Draft DAAP August 2026 * a DPoP-bound token carries the public-key thumbprint in cnf.jkt as defined by [RFC9449]; or * an mTLS-bound token carries the certificate thumbprint in cnf as defined by [RFC8705]. An authorization server MUST NOT emit cnf solely because a public key was uploaded. It MUST first establish proof of possession. The resource server MUST verify the DPoP proof or mutual-TLS binding on every protected request. This profile defines no short aliases for scope, client_id, act, or authorization_details. Private implementation claims MAY be used only under collision-resistant names and MUST NOT be required for interoperability. 5.2. Validation A resource server MUST validate at least: 1. an explicitly allowed signature algorithm and a valid signature; 2. iss against the configured authorization server; 3. aud against the resource server's identifier; 4. exp, iat, and any applicable not-before constraint; 5. the required values in scope; 6. the sender constraint represented by cnf; and 7. revocation or token status when the deployment's risk model requires online state. The resource server MUST NOT treat signature verification alone as sufficient authorization. 6. Delegation Delegation uses OAuth Token Exchange [RFC8693]. The delegating token is the subject_token. When an agent or service is acting as a distinct actor, the authorization server represents that chain using the standard act claim. Kumar Expires 3 March 2027 [Page 9] Internet-Draft DAAP August 2026 The authorization server MUST authenticate the requesting client and validate the subject token before exchange. It MUST reject a requested scope that is not contained in the subject token, and it MUST reject a resource that is broader than or inconsistent with the original authorization. A delegated token: * MUST NOT expire later than the subject token; * MUST be sender-constrained to the receiving Agent Client Instance; * MUST use a scope set no broader than the subject token; * MUST preserve the Principal as sub unless another specification defines a subject transition; and * MUST represent the current actor and any nested actor chain as specified by [RFC8693]. Deployments SHOULD bound delegation depth and SHOULD support revoking all tokens derived from a root authorization. Database parent identifiers and cascade algorithms are implementation details, not JWT claims defined here. Cross-domain delegation should be evaluated against OAuth Identity and Authorization Chaining [I-D.ietf-oauth-identity-chaining] rather than creating an incompatible chain format. 7. Refresh Tokens Refresh-token handling MUST follow [RFC9700]. Public clients MUST use refresh token rotation or sender-constrained refresh tokens. This profile requires both rotation and sender constraint for Agent Client Instances. On a successful refresh, the authorization server MUST invalidate the presented refresh token and return a new refresh token atomically. The new access token MUST NOT expand the original resource, scope, delegation, sender binding, or grant lifetime. 7.1. Lost-Response Recovery Network failure can occur after the authorization server commits rotation but before the client receives the response. A deployment MAY provide bounded recovery for this case. The transport syntax for a recovery key is an implementation extension and is not part of core conformance. Kumar Expires 3 March 2027 [Page 10] Internet-Draft DAAP August 2026 If recovery is provided, all of the following requirements apply: 1. Before its first attempt, the client generates a high-entropy recovery key and persists it with the old refresh token until the response is durable. 2. Every transport retry of that same refresh request uses the same recovery key. A new logical refresh operation uses a new key. 3. The authorization server binds recovery state to the authenticated client, Agent Client Instance, old refresh token, and recovery key. 4. Recovery returns the exact committed access token and rotated refresh token; it MUST NOT mint a new token, extend a lifetime, or rotate again. 5. Recovery is allowed only while the rotated child refresh token is active and unused. 6. The recovery window MUST be short and bounded. This profile RECOMMENDS no more than 300 seconds. 7. A different or missing recovery key, an expired recovery window, or an already-used child token is treated as refresh-token reuse and MUST fail. A server crash before transaction commit leaves the old token unused and the client can retry normally. A crash after commit is the lost- response case above and requires durable recovery state. Implementations MUST test both boundaries. 8. Operational Extensions The following topics are intentionally outside core conformance: * tamper-evident audit storage and external witnessing; * policy decision points and policy languages; * financial budgets and atomic debit ledgers; * event streams and webhooks; * credential vaults; * anomaly detection; and Kumar Expires 3 March 2027 [Page 11] Internet-Draft DAAP August 2026 * enterprise provisioning and SSO configuration. An implementation MUST NOT claim that an operator-signed hash chain is operator-independent evidence. Such a claim requires publication to or countersignature by an independent witness. If JSON records are hashed across implementations, canonicalization should use the JSON Canonicalization Scheme [RFC8785] and SHA-256 should be specified using [RFC6234]. Financial constraints should use structured authorization details [RFC9396], including an unambiguous amount representation and currency, rather than a bare numeric JWT claim. Potential extension documents are listed in the source repository. Their presence does not imply IETF submission, adoption, or interoperability. 9. Security Considerations The OAuth threat model and mitigations in [RFC9700] apply. This section calls out agent-specific consequences. 9.1. Consent Substitution A developer API key, policy-engine decision, or agent assertion is not the Principal's consent. Conflating these identities lets the party requesting authority approve its own request. Live consent therefore requires independent Principal authentication and request- bound approval. 9.2. Redirect and Authorization Request Integrity Exact redirect matching, PAR, PKCE S256, and state are mandatory. These controls address different attacks and are not substitutes for one another. Clients MUST keep state, the PKCE verifier, and the PAR request association confidential until the flow completes. 9.3. Audience and Sender Binding Bearer tokens are especially hazardous for autonomous software because agents may pass data through tools, logs, prompts, and subprocesses. Resource binding limits where a token can be used; sender constraint limits who can use it. This profile requires both. Kumar Expires 3 March 2027 [Page 12] Internet-Draft DAAP August 2026 9.4. Agent-Key Enrollment Accepting an uploaded public key without proof of possession enables an attacker to register somebody else's key or create unusable identities. Authorization servers MUST verify possession and MUST define secure key rotation and recovery procedures. 9.5. Delegation Every delegation hop increases the attack surface. Scope and resource attenuation, bounded lifetime, sender constraint, depth limits, and root revocation SHOULD be enforced together. A textual claim that an agent is a sub-agent is not sufficient. 9.6. Refresh Reuse Recovery must not become a replay grace period. Only the same authenticated and request-bound retry can receive the previously committed response. Any other reuse can indicate token theft and SHOULD trigger family revocation or another risk-appropriate incident response. 9.7. Logging Authorization servers and resource servers MUST NOT log authorization codes, refresh tokens, access tokens, DPoP private keys, PKCE verifiers, recovery keys, or upstream credentials. Security logs SHOULD record enough non-secret context to investigate consent, delegation, refresh reuse, and revocation events. 10. Privacy Considerations Agent authorization data can reveal a Principal's services, activities, relationships, and intended actions. Implementations SHOULD minimize token claims and consent records, use pairwise subject identifiers where appropriate, and avoid placing personal data in globally resolvable agent documents. Resource indicators and fine-grained scopes can themselves be sensitive. They SHOULD be disclosed only to parties that require them. Audit retention and export must have a defined purpose, access policy, retention period, and deletion process. Delegation chains reveal relationships among services and actors. A resource server should receive only the chain information needed for its authorization decision. Kumar Expires 3 March 2027 [Page 13] Internet-Draft DAAP August 2026 11. IANA Considerations This document requests no IANA actions. It uses claims, parameters, endpoints, and confirmation methods defined by existing OAuth and JOSE specifications. Any future wire-level recovery key or agent- specific authorization detail will require separate specification and appropriate registry review. 12. Relationship to Other Work OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] addresses identity and authorization continuity across trust domains. Implementations should use that work for cross-domain chains rather than defining private equivalents. OAuth Transaction Tokens address short-lived, purpose-bound tokens for a transaction [I-D.ietf-oauth-transaction-tokens]. They may complement this profile for multi-service call chains; this document does not redefine transaction tokens. The agent authorization use-cases draft [I-D.chen-oauth-agent-authz-use-cases] surveys emerging scenarios and gaps. The multi-agent collaboration draft [I-D.song-oauth-ai-agent-collaborate-authz] explores group authorization. This profile focuses more narrowly on a high- assurance OAuth authorization and delegation baseline and does not claim to supersede either effort. 13. Implementation Status This section follows the intent of [RFC7942] and is expected to be removed before publication as an RFC. Grantex provides an implementation-specific JSON API inspired by this profile. As of 2026-08-30 it implements exact registered redirects and resources for profile-aware agents, PKCE S256 checks, live- consent WebAuthn checks, resource-bound JWTs, key-thumbprint cnf claims, scope attenuation, refresh-token rotation, and bounded request-bound recovery. Kumar Expires 3 March 2027 [Page 14] Internet-Draft DAAP August 2026 It is not yet a conformant implementation of this profile. In particular, its custom /v1/authorize and /v1/token endpoints are not the standard OAuth authorization and token endpoints; PAR is not implemented; DPoP proofs are not validated at protected resources; legacy agent registrations can omit profile metadata; and live Principal passkey enrollment is not yet anchored in an independent identity-provider ceremony. The repository's implementation report tracks these gaps. 14. Acknowledgements The author thanks reviewers in the OAuth community whose published work on OAuth security, identity chaining, transaction tokens, and agent authorization helped narrow this document. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Kumar Expires 3 March 2027 [Page 15] Internet-Draft DAAP August 2026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [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, . [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, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . 15.2. Informative References [DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July 2022, . [I-D.chen-oauth-agent-authz-use-cases] Chen, M., Chen, J., Yao, J., Jiang, Y., and P. C. Liu, "Agent Authorization use cases and gap analysis", Work in Progress, Internet-Draft, draft-chen-oauth-agent-authz- Kumar Expires 3 March 2027 [Page 16] Internet-Draft DAAP August 2026 use-cases-03, 25 August 2026, . [I-D.ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, . [I-D.song-oauth-ai-agent-collaborate-authz] Song, Y., Lun, L., Jiang, Y., and F. Liu, "OAuth2.0 Extension for Multi-AI Agent Collaboration", Work in Progress, Internet-Draft, draft-song-oauth-ai-agent- collaborate-authz-02, 30 June 2026, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Kumar Expires 3 March 2027 [Page 17] Internet-Draft DAAP August 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . Appendix A. Non-Normative Grantex Mapping This appendix is informative. It helps reviewers compare the profile with the Grantex reference implementation; it does not define interoperable endpoints. +======================+======================================+ | Profile operation | Grantex implementation-specific path | +======================+======================================+ | Agent registration | POST /v1/agents | | metadata | | +----------------------+--------------------------------------+ | Authorization | POST /v1/authorize | | request | | +----------------------+--------------------------------------+ | Principal consent | POST /v1/consent/{id}/approve | +----------------------+--------------------------------------+ | Code exchange | POST /v1/token | +----------------------+--------------------------------------+ | Refresh rotation | POST /v1/token/refresh | +----------------------+--------------------------------------+ | Token status | POST /v1/tokens/verify | +----------------------+--------------------------------------+ | Grant revocation | DELETE /v1/grants/{id} | +----------------------+--------------------------------------+ | Delegation | POST /v1/grants/delegate | +----------------------+--------------------------------------+ | Authorization-server | GET /.well-known/oauth- | | metadata | authorization-server | +----------------------+--------------------------------------+ | Signing keys | GET /.well-known/jwks.json | +----------------------+--------------------------------------+ Table 1 The implementation transports its refresh recovery key in an Idempotency-Key HTTP request header. That header use is implementation specific in this revision and is not required for DAAP core conformance. Kumar Expires 3 March 2027 [Page 18] Internet-Draft DAAP August 2026 Appendix B. Candidate Extension Documents The following subjects should be developed independently if there is community interest: 1. externally witnessed agent audit checkpoints; 2. financial authorization details and atomic budget settlement; 3. agent delegation lifecycle and cascade revocation profiles; and 4. operational event, policy, and credential-handling interfaces. Separating these topics keeps security assumptions, registries, and consensus boundaries reviewable. Appendix C. Author's Address Sanjeev Kumar Orchestrum Technologies LLP Email: mishra.sanjeev@gmail.com Alternate email: sanjeev@orchestrum.in URI: https://grantex.dev Author's Address Sanjeev Kumar Orchestrum Technologies LLP Email: mishra.sanjeev@gmail.com URI: https://grantex.dev Kumar Expires 3 March 2027 [Page 19]