Network Working Group J. Azam, Ed. Internet-Draft MNKI AgentOS Intended status: Informational 16 September 2026 Expires: 20 March 2027 The Agent Trust Profile: Verifiable Authority for Autonomous Agents draft-mnki-agent-trust-profile-00 Abstract Autonomous AI agents act on behalf of people and organizations across system and organizational boundaries. Existing credentials establish that a token is valid; they do not express which agent is acting, for whom, under what delegated authority, within which constraints, and whether that authority is still current. This document profiles existing standards — JWS, OAuth/OIDC, SPIFFE/WIMSE workload identity, DPoP-style proof of possession, OpenID AuthZEN and OpenID Federation — to carry those semantics: agent identity and principal binding, delegation with authority attenuation, capability-based authorization with constraints, request proof of possession, authorization attestations, tamper-evident provenance, revocation, and cross- organization trust. It defines no new cryptography, transport or token format. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Azam Expires 20 March 2027 [Page 1] Internet-Draft agent-trust-profile September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 3 4. Principal Binding . . . . . . . . . . . . . . . . . . . . . . 4 5. Capabilities, Constraints and Attenuation . . . . . . . . . . 4 6. Delegation Credential . . . . . . . . . . . . . . . . . . . . 4 7. Request Proof of Possession . . . . . . . . . . . . . . . . . 4 8. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 4 9. Authorization Attestation . . . . . . . . . . . . . . . . . . 5 10. Provenance . . . . . . . . . . . . . . . . . . . . . . . . . 5 11. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 5 12. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 5 13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 5 14. Security Considerations . . . . . . . . . . . . . . . . . . . 6 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 16.1. Normative References . . . . . . . . . . . . . . . . . . 6 16.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction An agent request today typically carries a bearer token. A relying party can conclude "this credential is valid" but not "this specific agent, acting for this principal, holds delegated authority for this action under these limits, and that authority has not been revoked". The profile fills that gap with verifiable objects layered on existing standards. Conformance is defined by executable vectors (Section 12). 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD", "MAY" are to be interpreted as described in [RFC2119]. All signed objects are compact JWS [RFC7515] with JOSE headers alg, typ and kid; alg MUST be ES256 or EdDSA. Public keys are JWKs [RFC7517]. Timestamps are ISO 8601 in UTC. Canonicalization for hashing is JCS [RFC8785]. Azam Expires 20 March 2027 [Page 2] Internet-Draft agent-trust-profile September 2026 2. Model +==============+====================================================+ | Term | Meaning | +==============+====================================================+ | Agent | Cryptographically identifiable | | | software actor with a stable | | | identifier, lifecycle and credentials | +--------------+----------------------------------------------------+ | Principal | The human, service or organization | | | the agent acts for; always distinct | | | from the agent | +--------------+----------------------------------------------------+ | Organization | The trust domain that operates the | | | agent and signs its delegations and | | | attestations | +--------------+----------------------------------------------------+ | Capability | {action, resource, constraints?} — a | | | machine-evaluable unit of authority | +--------------+----------------------------------------------------+ | Delegation | A grant of capabilities from an | | | issuer to a subject agent with | | | validity and status | +--------------+----------------------------------------------------+ | Effective | The intersection of every grant in | | authority | the chain, never the union | +--------------+----------------------------------------------------+ | Decision | ALLOW, DENY or REQUIRE_APPROVAL, | | | derived from evidence rows | +--------------+----------------------------------------------------+ Table 1 3. Agent Identity An agent identifier MUST be URI-safe, stable, non-secret and unique within its organization. SPIFFE IDs [SPIFFE], DIDs, OIDC subjects and organization-specific URIs are acceptable. Lifecycle states are pending, active, suspended, revoked, retired; only active agents may be authorized. Credentials bind a public JWK to the agent (kid, not_before, not_after, issuer, status). Issuer-signed identity tokens ([RFC7519] JWT-SVIDs, IdP JWTs) MAY be presented in the Agent- Credential header and validated against configured trust anchors (OIDC issuers via discovery JWKS; SPIFFE trust domains via their bundle endpoint); a valid presented token MAY stand in for a registered key. Azam Expires 20 March 2027 [Page 3] Internet-Draft agent-trust-profile September 2026 4. Principal Binding Every agent SHOULD carry an owner principal. Verifiers MUST report the principal as separate evidence and MUST NOT conflate agent and principal. 5. Capabilities, Constraints and Attenuation action is exact; resource is exact or a trailing-* prefix. Constraint keys defined here: max_value and max_total (numbers), currency (ISO 4217), region (list). A child capability is covered by a parent when actions are equal, the parent resource contains the child resource, and the child constraints are tighter (max_value/ max_total not greater; region a subset; other keys equal). Delegation MUST refuse anything wider (exceeds_parent). max_total denotes a lifetime budget across allowed requests. 6. Delegation Credential Type agent-trust-delegation+jwt. Claims: iss (organization), sub (subject agent), jti (delegation id), iat, optional nbf/exp, and atp with v (1), issuer ({type, id}), capabilities, constraints, effective, parent, parent_hash (base64url SHA-256 of the parent JWS), depth, task. A chain root MUST be issued by a principal at depth 0; each child MUST be issued by the parent's subject, reference its parent by jti and parent_hash, increment depth, and satisfy capabilities ⊆ parent effective with effective = attenuate(parent effective, capabilities). Chains MUST NOT exceed depth 8. 7. Request Proof of Possession A detached JWS of type agent-trust-proof+jwt in the Agent-Proof header, modelled on DPoP [RFC9449]: iss (agent), htm, htu (scheme and host lower-cased, no query or fragment), iat, exp, jti, rh (base64url SHA-256 of the exact request body). Verifiers MUST check the signature against the credential named by kid, htm, htu, rh, expiry and skew, and SHOULD reject replayed jti values. 8. Authorization Authority is checked first and is default-deny; policy narrows. A policy document {version: 1, default?, rules[]} with rules {id, match?, conditions?, effect} fires every rule whose match and conditions hold; precedence is deny > require_approval > allow; the document default applies when nothing fires. Conditions: amount_lte, amount_gt, currency_in, region_in, requires_attestation, missing_attestation, delegation_depth_lte, delegation_depth_gt, time_window. Evaluation MUST be deterministic. A policy decision Azam Expires 20 March 2027 [Page 4] Internet-Draft agent-trust-profile September 2026 point exposing this evaluation SHOULD implement the AuthZEN evaluation request [AUTHZEN]. Human approval is a first-class signed object (agent-trust-approval+jwt) bound to the decision's request hash. 9. Authorization Attestation Type agent-trust-attestation+jwt, short-lived, issued by the organization from an ALLOW decision or an approved REQUIRE_APPROVAL decision: iss, sub (agent), jti, iat, exp, optional aud, and atp with principal, organization, action, resource, decision, capabilities (effective), delegation_chain, human_approval, decision_id, request_hash, policy_version. A relying party MUST verify signature, type, expiry, subject, action and resource coverage, and SHOULD check revocation by jti. 10. Provenance Each consequential event is a CloudEvents-shaped [CLOUDEVENTS] envelope hash-chained per organization (prev_hash, hash = SHA- 256(JCS(envelope))), signed with the organization key (es256::) or an HMAC. Stores MUST be append-only. A signed ledger-head checkpoint (agent-trust-ledger-head+jwt) enables external anchoring. 11. Revocation Subjects: agent, credential, delegation, attestation, policy version. Revoking any link of a delegation chain invalidates every descendant at verification time. Short-lived credentials plus an indexed status lookup are RECOMMENDED. 12. Federation Organizations publish an entity configuration (keys, endpoints, authority_hints) and MAY act as anchors publishing signed subordinate statements (entity-statement+jwt), following the shape of OpenID Federation [OIDFED]. Trust level 1 recognises an organization; level 2 permits its attested agents to act under the relying organization's policy. Peer revocation lists are not consulted in this version; attestation lifetimes bound the exposure. 13. Conformance Three levels: Level 1 Verifier (decision vectors), Level 2 Credentials (signed-object vectors), Level 3 Federation. An implementation claims a level only when every vector of that level and all lower levels is reproduced. Azam Expires 20 March 2027 [Page 5] Internet-Draft agent-trust-profile September 2026 14. Security Considerations The model is not trusted: an agent's proposal never carries authority by itself. Replay of request proofs is bounded by jti tracking and short lifetimes. Attestations are short-lived because peer revocation is not consulted across organizations. Budget enforcement requires the ledger; snapshot-based verifiers MUST flag decisions taken without it. Debuggable enclaves MUST NOT yield verified TEE attestations. 15. IANA Considerations This document requests registration of the media types application/ agent-trust-proof+jwt, application/agent-trust-delegation+jwt, application/agent-trust-attestation+jwt, application/agent-trust- approval+jwt and application/agent-trust-ledger-head+jwt in the "Media Types" registry, and of the HTTP header fields Agent-Proof, Agent-Credential and Agent-Attestation in the "Hypertext Transfer Protocol (HTTP) Field Name Registry". 16. References 16.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, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Azam Expires 20 March 2027 [Page 6] Internet-Draft agent-trust-profile September 2026 [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, . 16.2. Informative References [AUTHZEN] "OpenID AuthZEN Authorization API 1.0", n.d., . [OIDFED] "OpenID Federation 1.0", n.d., . [SPIFFE] "SPIFFE: Secure Production Identity Framework for Everyone", n.d., . [CLOUDEVENTS] "CloudEvents 1.0", n.d., . Appendix A. Acknowledgements The profile builds on the work of the IETF WIMSE and OAuth working groups, the OpenID Foundation AuthZEN and Federation working groups, the SPIFFE project, and the Model Context Protocol and Agent-to-Agent communities. Author's Address Javvad Azam (editor) MNKI AgentOS Netherlands Email: javvad@mnki.com URI: https://mnki.com Azam Expires 20 March 2027 [Page 7]