Workload Identity in Multi-System Environments K. Rampalli Internet-Draft Glyphzero Labs Inc. Intended status: Standards Track 25 April 2026 Expires: 27 October 2026 PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems draft-rampalli-pedigree-00 Abstract This document defines PEDIGREE (Per-Agent Delegation Identity with Governance-Enforced Execution), an identity and delegation framework for AI agents that extends the workload-identity model of SPIFFE (RFC 9542 / draft-ietf-wimse) with cryptographic per-hop delegation, monotonic scope attenuation enforced at mint and at verify, and dual- layer authority enforcement combining an operator-controlled ceiling with per-parent mandate narrowing. PEDIGREE complements AAuth (draft-hardt-aauth-protocol) and AIP (draft-prakash-aip) by providing: (a) dual-enforcement semantics absent from both, (b) Cedar-policy mandates with static-analysis proofs of narrowing, (c) strict cryptographic parent-token re- verification that catches parent-swap attacks missed by append-only token chains, and (d) a native bridge to existing SPIFFE deployments. 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 27 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Rampalli Expires 27 October 2026 [Page 1] Internet-Draft PEDIGREE April 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. 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. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identity Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Identifier Schemes . . . . . . . . . . . . . . . . . . . 5 3.2. Root of Trust . . . . . . . . . . . . . . . . . . . . . . 5 4. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Payload (SIT Claims) . . . . . . . . . . . . . . . . . . 5 4.3. Required Invariants . . . . . . . . . . . . . . . . . . . 6 5. Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Mint . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Verify (Strict) . . . . . . . . . . . . . . . . . . . . . 7 5.3. Parent-Swap Resistance . . . . . . . . . . . . . . . . . 7 6. Dual Enforcement . . . . . . . . . . . . . . . . . . . . . . 7 7. Mandate Narrowing . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Narrowing Check . . . . . . . . . . . . . . . . . . . . . 8 7.2. Static Analysis . . . . . . . . . . . . . . . . . . . . . 8 8. Completion Blocks . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. Chain Binding . . . . . . . . . . . . . . . . . . . . . . 9 9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Cascade . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Shared Signals Framework . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11.1. JWT "typ" Header Value . . . . . . . . . . . . . . . . . 10 11.2. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 10 11.3. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Comparison with AAuth and AIP . . . . . . . . . . . 11 Appendix B. Reference Implementations . . . . . . . . . . . . . 12 Rampalli Expires 27 October 2026 [Page 2] Internet-Draft PEDIGREE April 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1. Problem Agentic AI systems spawn sub-agents dynamically. Current identity frameworks fail three tests: 1. *Attribution* -- when an orchestrator spawns a sub-agent to book flights and another to file expenses, both share the orchestrator's ambient credentials. Incident response cannot determine which sub-agent took which action. 2. *Attenuation* -- sub-agents typically inherit all parent authority. AAuth explicitly rejects scope attenuation (draft- hardt-aauth-protocol-01 Appendix C.3.7). Bearer-token and OAuth flows have no delegation narrowing primitive. 3. *Enforcement* -- even protocols that define attenuation (AIP) defer aggregate budget enforcement to "the orchestration platform at runtime" (draft-prakash-aip-00 Section 7.4), leaving a single- layer guard vulnerable to orchestrator compromise. 1.2. Non-Goals * Replacing SPIFFE/WIMSE workload identity for in-cluster service- to-service auth. PEDIGREE is an upper layer that delegates from a SPIFFE-bearing root. * Defining a user-authentication protocol. OIDC/OAuth flows bootstrap the root consent; PEDIGREE governs what happens after. * Specifying an authorization policy language. PEDIGREE accepts Cedar (RECOMMENDED), Datalog, or Rego as mandate policy formats. 1.3. Related Work The following table compares PEDIGREE with existing protocols across key delegation and enforcement dimensions. Rampalli Expires 27 October 2026 [Page 3] Internet-Draft PEDIGREE April 2026 +=========+====================+============+=========+============+ |Protocol | Sub-agent identity |Scope |Per-hop |Dual | | | |attenuation |audit |enforcement | +=========+====================+============+=========+============+ |AAuth | No |Explicitly |Mission- |No | |(draft- | |rejected |level | | |hardt) | | | | | +---------+--------------------+------------+---------+------------+ |AIP | Yes |Yes |Mandatory|No (budget | |(draft- | (aip:key:ed25519:) |(Biscuit) |context |punted) | |prakash) | | | | | +---------+--------------------+------------+---------+------------+ |SPIFFE | Per-workload |None |Workload-|No | |SVID | | |level | | +---------+--------------------+------------+---------+------------+ |ZeroID | Yes (RFC 8693) |Yes |CAEP |No | |(open- | | |cascade | | |source) | | | | | +---------+--------------------+------------+---------+------------+ |PEDIGREE | Yes (parent_chain) |Yes (Cedar, |Consent |Yes (ceiling| |(this | |mint+verify)|chain + |intersect | |document)| | |SIEM |mandate) | +---------+--------------------+------------+---------+------------+ Table 1: Protocol Comparison 2. Terminology 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. Root A human principal whose initial consent establishes the delegation chain. Primary Agent A long-lived agent holding a signing keypair, directly delegated-to by the root. Sub-Agent An ephemeral agent issued a PEDIGREE by a primary or another sub-agent. PEDIGREE A signed JWT carrying principal identity, parent chain, mandate (policy set), public key, and lifetime. SIT Suradar Identity Token -- the concrete wire format of a PEDIGREE, compatible with RFC 7519. Rampalli Expires 27 October 2026 [Page 4] Internet-Draft PEDIGREE April 2026 Mandate A typed policy set (Cedar by default) defining what actions an agent may perform on which resources. Ceiling The deployment-level policy set defined by the operator; applies to all agents regardless of individual mandates. Consent Chain An ordered sequence of principal-issued consents authorizing transitive delegation, with optional depth limits. 3. Identity Model 3.1. Identifier Schemes PEDIGREE defines two identifier schemes: Named (registry-backed) Format: pedigree:name:/ Example: pedigree:name:glyphzero/trading-orchestrator-7f3a Self-certifying (registry-free) Format: pedigree:key:ed25519: Example: pedigree:key:ed25519:z6MkpZ... RECOMMENDED for sub-agents with lifetimes under 5 minutes. 3.2. Root of Trust Each chain terminates at a root principal (human, identified via OIDC/OAuth). The primary agent's PEDIGREE carries the root's sub claim and a signature over the initial consent. 4. Token Format 4.1. Header { "alg": "EdDSA", "typ": "pedigree+jwt" } 4.2. Payload (SIT Claims) The following is the set of claims carried in a SIT payload: Rampalli Expires 27 October 2026 [Page 5] Internet-Draft PEDIGREE April 2026 { "iss": "", "sub": "", "jti": "", "iat": 1712345678, "exp": 1712349278, "pedigree_version": "0.1", "agent_pub": "", "parent_chain": ["", ""], "delegation_depth": 2, "scopes": ["read:cal", "write:cal"], "mandate": { "format": "cedar", "policy_set": "permit(principal, action == PedigreeAction::\"read_file\", resource);" }, "consent_chain": [""], "ceiling_ref": "sha256:", "completion_bindable": true } 4.3. Required Invariants 1. delegation_depth == len(parent_chain) 2. scopes MUST be a subset of the immediate parent's scopes. 3. exp - iat MUST NOT exceed the parent's remaining lifetime. 4. mandate.policy_set MUST narrow or equal the parent's mandate under the static-analysis check of Section 7. 5. Delegation 5.1. Mint To mint a child SIT, the parent: 1. Verifies its own SIT is unexpired and not revoked. 2. Chooses a subset of its scopes. 3. Generates (or receives) the child's public key. 4. Computes a child mandate that is provably narrower than the parent's (see Section 7). 5. Appends its own jti to the child's parent_chain. Rampalli Expires 27 October 2026 [Page 6] Internet-Draft PEDIGREE April 2026 6. Signs the child JWT with its own private key. 5.2. Verify (Strict) Verifiers MUST: 1. Cryptographically verify the leaf SIT against the issuer's public key. 2. Retrieve each parent JWT referenced by parent_chain and cryptographically verify each. 3. Check each parent's sub equals the corresponding parent_chain entry of the descendant. 4. Check each hop's scopes is a subset of the prior hop's scopes. 5. Check each hop's mandate is a narrowing of the prior hop's mandate via static analysis (Section 7). 6. Check the leaf's ceiling_ref hash matches the operator's current ceiling or a published prior version within grace period. 5.3. Parent-Swap Resistance Because verification re-verifies each parent against the issuer's public key, an attacker cannot substitute a same-scope parent from a different chain. AIP's Biscuit append-only semantics trust block signatures and do not re-verify upstream; PEDIGREE's explicit re- verification catches this attack class. 6. Dual Enforcement Every authorization decision requires both: 1. *Mandate:* the SIT's mandate.policy_set permits the action (parent's delegation narrowing). 2. *Ceiling:* the operator-deployed ceiling policy permits the action (applies to all agents). Pseudocode: allow = mandate.evaluate(action, resource) && ceiling.evaluate(action, resource) Rampalli Expires 27 October 2026 [Page 7] Internet-Draft PEDIGREE April 2026 The ceiling is identified by ceiling_ref (SHA-256 of the operator- signed ceiling policy document) and distributed out-of-band (or via a well-known URL). This primitive is absent from AAuth, AIP, SPIFFE, and ZeroID. 7. Mandate Narrowing 7.1. Narrowing Check A child mandate M_c narrows a parent mandate M_p if and only if: forall (action, resource). M_c.permits(action, resource) => M_p.permits(action, resource) 7.2. Static Analysis When mandate.format == "cedar", implementations MUST emit a static- analysis proof that M_c narrows M_p. Cedar's published analyzer (AWS 2024) suffices. The proof artifact MAY accompany the SIT as a narrowing_proof field referencing the proof by content hash. This static-proof primitive is absent from AIP (Biscuit semantics enforce narrowing imperatively but do not emit a verifiable artifact). 8. Completion Blocks 8.1. Purpose A completion block cryptographically binds the outcome of an agent's action to the delegation chain that authorized it, enabling downstream verifiers to prove a result came from an authorized chain without trusting out-of-band audit logs. 8.2. Format { "jti": "", "parent_sit": "", "status": "completed", "result_hash": "sha256:", "verification_status": "self_reported", "cost_cents": 1234, "timestamp": "", "signing_agent": "" } Rampalli Expires 27 October 2026 [Page 8] Internet-Draft PEDIGREE April 2026 The status field MUST be one of: "completed", "failed", or "partial". The verification_status field MUST be one of: "self_reported", "tool_verified", "peer_verified", or "human_verified". The completion block is signed by the executing agent's private key. Verifiers check the signature against agent_pub of the referenced SIT. 8.3. Chain Binding A downstream agent receiving a result from an upstream agent SHOULD require the completion block alongside the result. The receiving agent MAY refuse to consume un-bound results. 9. Revocation 9.1. Cascade Revoking a consent or a parent SIT invalidates every descendant in the chain. Implementations MUST walk the consent chain when evaluating revocation. 9.2. Shared Signals Framework Implementations SHOULD emit OpenID SSF events (credential-change, session-revoked) on revocation to propagate to connected IdPs. See draft-rampalli-suradar-bindings for CAEP event schema. 10. Security Considerations Parent-swap Mitigated by strict cryptographic re-verification (Section 5.3). Scope escalation Mitigated by subset check at mint AND at verify. Ceiling bypass Mitigated by dual enforcement (Section 6). Audit evasion Mitigated by mandatory context on each delegation block and by cryptographic completion blocks (Section 8). Key compromise Ephemeral self-cert keys (Section 3.1) limit blast radius to their TTL. Replay jti uniqueness enforced by nonce store. Transitive consent ConsentChain with TransitiveConsent=false blocks downstream delegation. Rampalli Expires 27 October 2026 [Page 9] Internet-Draft PEDIGREE April 2026 11. IANA Considerations This document requests the following registrations: 11.1. JWT "typ" Header Value Registration of the "pedigree+jwt" value in the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)" registry: Type Header Parameter Value pedigree+jwt Specification Document This document, Section 4.1 11.2. URI Scheme Provisional registration of the "pedigree" URI scheme with two defined forms: * pedigree:name:/ * pedigree:key:ed25519: 11.3. Well-Known URI Registration of the well-known URI /.well-known/pedigree-agent.json per RFC 8615. 12. References 12.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . Rampalli Expires 27 October 2026 [Page 10] Internet-Draft PEDIGREE April 2026 [RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9542] Gilman, E. and E. Baier, "SPIFFE Identity and Verifiable Identity Document", RFC 9542, DOI 10.17487/RFC9542, February 2024, . 12.2. Informative References [I-D.hardt-aauth-protocol] Hardt, D., "AAuth Protocol", Work in Progress, Internet- Draft, draft-hardt-aauth-protocol-01, March 2026, . [I-D.prakash-aip] Prakash, A., "Agent Interoperability Protocol", Work in Progress, Internet-Draft, draft-prakash-aip-00, March 2026, . [CEDAR] Amazon Web Services, "Cedar: A Language for Expressing Authorization Policies", https://www.cedarpolicy.com/, 2023. [SPIFFE-SPEC] CNCF SPIFFE Project, "SPIFFE/SPIRE Specification v1.0", https://spiffe.io/, 2023. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . Appendix A. Comparison with AAuth and AIP A detailed landscape comparison of PEDIGREE, AAuth, and AIP across all delegation, enforcement, and audit dimensions is maintained in the companion document: draft-rampalli-pedigree-landscape-comparison. Key differentiators summarized: * AAuth (draft-hardt-aauth-protocol-01) explicitly rejects scope attenuation and provides no sub-agent identity primitive. PEDIGREE adds both. Rampalli Expires 27 October 2026 [Page 11] Internet-Draft PEDIGREE April 2026 * AIP (draft-prakash-aip-00) provides sub-agent identity and Biscuit-based attenuation but defers budget enforcement to the orchestration platform and does not emit static-analysis proofs. PEDIGREE adds dual enforcement and Cedar-based narrowing proofs. Appendix B. Reference Implementations Go github.com/glyphzero/suradar -- production implementation covering L1-L3 of the SURADAR stack. Python Planned. TypeScript Planned. Author's Address Karthik Rampalli Glyphzero Labs Inc. Email: karthik@phantomcorgi.com Rampalli Expires 27 October 2026 [Page 12]