Heterogeneous Credential Verification for Workload and Agentic Systems
draft-jiang-wimse-heterogeneous-credential-00

WIMSE                                                           Y. Jiang
Internet-Draft                                                   D. Wang
Intended status: Standards Track                                 Y. Song
Expires: 25 December 2026                                         F. Liu
                                                                  Huawei
                                                            23 June 2026

 Heterogeneous Credential Verification for Workload and Agentic Systems
             draft-jiang-wimse-heterogeneous-credential-00

Abstract

   Workloads in multi-system environments, including AI agents acting on
   behalf of users and organizations, increasingly present multiple
   credentials of heterogeneous types within a single request: workload
   identity tokens, user-delegated OAuth access tokens, W3C Verifiable
   Presentations, X.509 certificates, platform-specific API keys, and
   security context artifacts such as attestation results.  These are
   issued by different authorities, follow different formats, are
   verified by different verifiers, and carry different assurance
   semantics.  A relying party that receives such a heterogeneous
   credential set has no common way to represent the set, identify each
   credential's type, determine the authoritative verifier for it,
   interpret verification results consistently, or combine multiple
   results into a single handling decision.

   This document defines a mechanism for processing a heterogeneous
   credential set on receipt.  It specifies a representation of the
   credential set, a procedure for identifying each credential's type
   and determining its verifier, a minimal common model for verification
   results that lets results from different verifiers be compared, and a
   policy model that combines multiple results into one handling
   decision.  The mechanism is transport-agnostic and does not constrain
   where the processing functions are deployed.

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/.

Jiang, et al.           Expires 25 December 2026                [Page 1]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   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 25 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Service-to-Service Calls in Multi-System Environments . .   5
     3.2.  Agent-to-Agent Task Delegation  . . . . . . . . . . . . .   5
     3.3.  Device-Hosted Agents and Domain-Specific Exposure . . . .   6
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Heterogeneous Credential Verification Mechanism . . . . . . .   7
     5.1.  Credential Set Representation . . . . . . . . . . . . . .   7
     5.2.  Type Identification and Verifier Determination  . . . . .   8
     5.3.  Verification Result Model . . . . . . . . . . . . . . . .   9
     5.4.  Decision Policy . . . . . . . . . . . . . . . . . . . . .  10
     5.5.  Function Placement  . . . . . . . . . . . . . . . . . . .  11
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Worked Example . . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Jiang, et al.           Expires 25 December 2026                [Page 2]
Internet-Draft    Heterogeneous Credential Verification        June 2026

1.  Introduction

   The WIMSE Working Group addresses the representation, propagation,
   and processing of workload identity in multi-system environments
   [I-D.ietf-wimse-arch], including workload identity credentials
   [I-D.ietf-wimse-workload-creds] and proof-of-possession mechanisms
   [I-D.ietf-wimse-wpt] for service-to-service interactions.  In
   deployed systems, however, a workload identity credential rarely
   travels alone.  A single inbound request frequently carries several
   credentials of different kinds, and the receiving side must make
   sense of all of them before the request can be handled.

   This situation is the norm, not the exception, in agentic
   deployments.  An AI agent invoking a tool, a service, or another
   agent may simultaneously present (a) a workload or agent identity
   credential attesting to the identity of the agent software itself,
   (b) a delegation credential conveying the authority of the human or
   organizational principal on whose behalf the agent acts, and (c)
   capability or scope tokens bounding what the agent may do; in some
   deployments the set also includes attestation results describing the
   integrity state of the platform executing the agent.  These
   credentials are issued by different authorities and follow different
   formats: WIMSE Workload Identity Tokens
   [I-D.ietf-wimse-workload-creds], OAuth 2.0 access tokens [RFC6749],
   JWTs [RFC7519], X.509 certificates [RFC5280], W3C Verifiable
   Credentials and Presentations [W3C.VC], and further token or context
   formats such as Entity Attestation Tokens [RFC9711] or proprietary
   API keys.  Each is verifiable only by a particular verifier or class
   of verifiers, and each carries its own assurance semantics, validity
   model, and freshness behavior.

   Existing specifications generally address these credential families
   one at a time.  They do not provide a common cross-credential model
   for a relying party that receives several of them together: how the
   credential set is represented and bound to the request, how each
   credential's type is identified, how the authoritative verifier or
   verifier class for each credential is determined, how verification
   results expressed in different vocabularies are interpreted
   consistently, and how multiple results, possibly partial or
   conflicting, are combined into a single decision on the handling of
   the request.

Jiang, et al.           Expires 25 December 2026                [Page 3]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   In the absence of common answers, every gateway, agent platform,
   relying party, or domain-specific exposure function implements its
   own ad hoc verification pipeline.  The observable consequences
   include inconsistent security posture across deployments, silent
   acceptance of credentials that could not actually be verified, and
   the inability to express or audit cross-credential policies such as
   "a high-risk action requires both a fresh attestation result and a
   valid user delegation token".

   This document defines a mechanism that supplies these common answers.
   After stating the problem (Section 4), it specifies how a
   heterogeneous credential set is represented (Section 5.1), how each
   credential's type is identified and its verifier determined
   (Section 5.2), a minimal common model for verification results
   (Section 5.3), and a policy model for combining results into a
   handling decision (Section 5.4).  The mechanism is described in terms
   of the information exchanged and the processing applied, not in terms
   of a particular deployment topology: the same functions may run
   within a relying party, within a gateway serving several relying
   parties, or in a dedicated service (Section 5.5).

2.  Terminology

   The terms "workload" and "trust domain" are used as defined in
   [I-D.ietf-wimse-arch].  The following additional terms are used:

   Presenting Entity:  The entity (typically a workload, an AI agent, or
      a user-delegated client) that originates a request and presents
      one or more credentials with it.

   Credential:  A verifiable artifact binding claims to the Presenting
      Entity or its execution context.  A credential may be carried by
      value, or by reference (information sufficient to retrieve or
      reconstruct the credential).

   Credential Set:  The collection of credentials presented with a
      single request.

   Credential Type:  A classification of a credential that determines
      which verifier or class of verifiers is competent to verify it.
      Examples: WIMSE Workload Identity Token, OAuth 2.0 access token,
      JWT bearer assertion, X.509 certificate, W3C Verifiable
      Presentation, EAT attestation evidence, platform API key.

   Verifier:  An entity capable of producing a verification result for

Jiang, et al.           Expires 25 December 2026                [Page 4]
Internet-Draft    Heterogeneous Credential Verification        June 2026

      one or more credential types.  Examples: an OAuth authorization
      server's introspection endpoint [RFC7662], a RATS Verifier
      [RFC9334], a PKI validation service, a Verifiable Credential
      verifier.

   Verifier Class:  A class of verifiers sharing a verification
      capability (e.g., "token introspection endpoint", "attestation
      verifier"), as distinct from a concrete verifier instance.

   Relying Party (RP):  The function that receives the original request
      from the Presenting Entity and must decide how to handle it.

   Verification Result:  The outcome of verifying a single credential,
      including at minimum a status (such as valid, invalid, or
      indeterminate), and possibly assurance level, verified claims,
      freshness information, and verifier identity.

   Decision Policy:  A rule set that maps a tuple of verification
      results, together with attributes of the request, to a handling
      decision for the request.

3.  Use Cases

3.1.  Service-to-Service Calls in Multi-System Environments

   A workload in one trust domain calls a service in another.  The
   request carries the caller's workload identity credential together
   with an end-user OAuth access token propagated from an earlier hop,
   and possibly further context such as a platform attestation result in
   regulated deployments.  The receiving service must verify the
   workload identity against its issuer and introspect the access token
   against a different authorization server, each by a different
   verifier, before deciding whether the combination is sufficient for
   the requested operation.  The workload identity credential is one
   element of the credential set, not the whole story.

3.2.  Agent-to-Agent Task Delegation

   An AI agent delegates a task to another agent across the Internet.
   The callee agent (or a gateway in front of it) receives the caller
   agent's identity credential, the delegation chain of the originating
   human or organizational principal, one or more task-scoped capability
   tokens, and possibly runtime assurance context about the caller's
   execution environment.  These artifacts originate in different trust
   domains and formats, and the callee must evaluate them together
   before accepting the delegated task.  This need is independent of
   which agent communication protocol carries the request.

Jiang, et al.           Expires 25 December 2026                [Page 5]
Internet-Draft    Heterogeneous Credential Verification        June 2026

3.3.  Device-Hosted Agents and Domain-Specific Exposure

   An agent hosted on a user device interacts with domain-specific
   services through an exposure interface.  Credentials anchored in
   different trust domains accompany the request: subscription-related
   credentials anchored in the service operator's domain, application-
   layer tokens anchored in a third-party identity provider, and device
   or platform assurance context anchored in another trust domain.  The
   receiving side must route each credential to the verifier that is
   authoritative for it and combine the outcomes under operator policy.

4.  Problem Statement

   The use cases share five recurring gaps, summarized here and
   addressed by the mechanism in Section 5.

   *  *Credential set representation.* There is no common way to convey
      a set of heterogeneous credentials with a request so that the
      receiver can enumerate the set, distinguish credentials carried by
      value from those carried by reference, and detect tampering.  Each
      credential tends to occupy its own protocol slot, making the set
      as a whole invisible: a relying party cannot tell whether a
      credential is absent because it was never presented or because it
      was stripped in transit.

   *  *Credential type identification.* A credential cannot be acted on
      until its type is known.  Some formats are self-describing, some
      are recognizable structurally, and some (opaque tokens, API keys)
      are indistinguishable without out-of-band context.  There is no
      shared vocabulary of credential type identifiers and no convention
      for declaring a type alongside a credential whose format is not
      self-describing.

   *  *Verifier determination.* Given a typed credential, some party
      must determine which verifier is authoritative for it.  This
      association has no standard expression, and there is no defined
      behavior when no authoritative verifier is known, the silent
      default, ignoring the credential, being the most dangerous.

   *  *Verification result normalization.* An OAuth introspection
      response [RFC7662], a RATS attestation result [RFC9334], a
      certificate path validation outcome, and a Verifiable Presentation
      report differ in structure, status granularity, assurance, and
      freshness.  Reasoning over several at once needs a common minimal
      model, and a defined treatment of the indeterminate outcome, which
      fails open if read as valid and fails closed if read as invalid.

Jiang, et al.           Expires 25 December 2026                [Page 6]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   *  *Multi-result decision policy.* Multiple results must be combined
      into one handling decision, conditioned on attributes such as
      operation type, request content, risk, credential precedence, and
      result freshness, with outcomes beyond allow and deny.  Such
      policies today are locked in proprietary configuration and cannot
      be exchanged or audited.

5.  Heterogeneous Credential Verification Mechanism

   This section defines the mechanism.  It is described in terms of five
   processing functions and the information each consumes and produces.
   The functions are presented in a natural order, but an implementation
   may interleave, parallelize, or short-circuit them as long as the
   externally observable result is equivalent; Section 5.5 discusses
   where the functions run.

   +------------+  request +       +------------------------------+
   | Presenting |  credential set  | Receiving side               |
   | Entity     |----------------->| (RP, gateway, platform,      |
   | (workload/ |                  |  or helper service)          |
   |  AI agent) |                  |                              |
   +------------+                  | (1) set enumeration          |
                                   | (2) type identification      |
                                   | (3) verifier determination   |
                                   | (4) result normalization     |
                                   | (5) decision policy          |
                                   +---------------+--------------+
                                                   |
                                                   | per-credential
                                                   | verification
                                                   v
                               +----------+ +----------+ +----------+
                               | Verifier | | Verifier | | Verifier |
                               | (OAuth)  | | (RATS)   | | (VC/PKI) |
                               +----------+ +----------+ +----------+

           Figure 1: Processing of a Heterogeneous Credential Set

5.1.  Credential Set Representation

   A request is accompanied by a Credential Set: an ordered list of
   Credential Entries together with a binding to the request.  The
   mechanism defines the following information for the set and for each
   entry; the concrete encoding (for example, a JSON object, a CBOR map,
   or a structured HTTP field) is left for working group discussion, and
   the field names below are descriptive.

   The Credential Set carries:

Jiang, et al.           Expires 25 December 2026                [Page 7]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   request-binding:  A value that ties the set to the specific request,
      for example a digest of the request's method, target, and
      security-relevant headers.  It lets a receiver detect a set
      replayed against a different request.

   set-digest:  A digest computed over the ordered enumeration of
      entries (specifically over each entry's type and a stable
      identifier of its credential).  Together with request-binding, it
      lets a receiver detect that an entry has been added, removed, or
      substituted in transit.  When the Presenting Entity can sign,
      signing set-digest binds the membership of the set to the
      Presenting Entity; this is the property that distinguishes a
      credential that was never presented from one that was stripped.

   entries:  The ordered list of Credential Entries.

   Each Credential Entry carries:

   type:  The credential type (Section 5.2), if known to the Presenting
      Entity; otherwise absent, to be determined by the receiver.

   conveyance:  Either "value" or "reference".

   credential:  Present when conveyance is "value": the credential
      itself.

   reference:  Present when conveyance is "reference": information
      sufficient for an authorized party to retrieve or verify the
      credential without the credential being carried inline, for
      example an introspection hint together with an issuer hint, a
      certificate digest with a retrieval locator, or an opaque evidence
      handle.

   A receiver enumerates the entries, recomputes set-digest over them,
   and checks it against the value carried in the set and, where
   present, against the Presenting Entity's signature.  A mismatch, or
   an absent expected entry (Section 5.4), is carried forward as an
   input to the decision rather than silently ignored.

5.2.  Type Identification and Verifier Determination

   For each entry whose type is not already supplied, the receiver
   determines a Credential Type.  Type is taken, in order of preference,
   from an explicit, integrity-protected declaration (such as a media
   type or a "typ" header parameter [RFC7519]); from the structural
   framing of a credential carried by value (JOSE or COSE framing, X.690
   DER, JSON-LD presentation framing); or from deployment context for
   credentials that are otherwise opaque.  How the type was determined

Jiang, et al.           Expires 25 December 2026                [Page 8]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   is retained, because it bounds the assurance that can be attached to
   the eventual result: a type taken from an integrity-protected
   declaration supports a stronger result than one inferred
   heuristically.

   The receiver then determines a Verifier for the credential using a
   Verifier Resolution Map, which associates a Credential Type with one
   of:

   a Verifier instance:  a concrete endpoint and the identity expected
      of it.  This is the direct association.

   a Verifier Class:  a category of verifier (for example, "OAuth
      introspection endpoint", "attestation verifier", "PKIX path
      validator") that is resolved to a concrete instance by
      configuration, by discovery such as authorization server metadata
      [RFC8414], or by association with the trust anchor under which the
      credential was issued.  This is the indirect association, and it
      is what allows the authoritative verifier to follow the
      credential's origin rather than being fixed by the receiver, which
      matters when the set spans trust domains.

   When the map yields no association for a Credential Type, the
   credential is treated as unverifiable: the receiver records a result
   with status "indeterminate" and a reason of "no-verifier"
   (Section 5.3) and carries it into the decision.  The credential is
   not dropped.

5.3.  Verification Result Model

   Each credential is verified by its determined Verifier using that
   verifier's native protocol (OAuth introspection [RFC7662], RATS
   appraisal [RFC9334], PKIX path validation, Verifiable Presentation
   verification, and so on).  The native outcome is projected onto a
   common Verification Result so that results from different verifiers
   can be compared.  A Verification Result carries:

   credential-type:  The type of the credential this result pertains to.

   status:  One of "valid", "invalid", or "indeterminate".  An
      unreachable verifier, an unresolved verifier, or an unidentifiable
      credential yields "indeterminate", not "valid" and not "invalid".

   reason:  Optional, refining a status (for example "expired",
      "verifier-unreachable", "no-verifier").

   verifier:  The identity of the verifier that produced the result.

Jiang, et al.           Expires 25 December 2026                [Page 9]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   produced-at:  The time the result was produced.

   fresh-until:  The time after which the result is to be treated as
      "indeterminate".  Defaulted per credential type when the verifier
      does not state one; attestation results typically carry a short
      bound, introspection results a longer one.

   Additional, type-specific information (an assurance level, a set of
   verified claims) may accompany a result; whether and how such
   information is normalized further is left for working group
   discussion.  The four-field core (status, verifier, produced-at,
   fresh-until) is what the decision function relies on.

5.4.  Decision Policy

   The decision function consumes the Verification Results for the set
   together with a Decision Context describing the request, and produces
   a single Handling Decision.  The Decision Context carries request
   attributes against which policy is evaluated:

   request-type:  The class of operation (for example read, write, tool-
      invocation, task-delegation).

   request-content:  Attributes derived from the request (for example
      target resource, parameter sensitivity).

   risk-level:  A risk classification assigned by the receiver or an
      upstream risk function.

   expected-types:  The credential types expected for this request
      class, so that an expected-but-absent type becomes an explicit
      "indeterminate" input rather than being overlooked.

   A policy maps the tuple of results and the Decision Context to one of
   the following Handling Decisions: "allow"; "deny"; "allow-with-
   constraints" (for example reduced scope, rate limiting, sandboxed
   execution); "step-up" (request additional or re-presented
   credentials); or "quarantine" (hold for review).  Deployments may
   define additional outcomes.

Jiang, et al.           Expires 25 December 2026               [Page 10]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   The mechanism does not fix a single policy language; it fixes the
   inputs (the result tuple and the Decision Context) and the outcome
   vocabulary, leaving the policy expression itself to deployment or to
   future work.  Two rules constrain any policy, because they capture
   the failure modes the mechanism exists to prevent: a result that is
   "indeterminate", or stale per its fresh-until bound, is not treated
   as "valid"; and for a request classified as high risk, the default
   decision in the presence of any "indeterminate" result is not
   "allow".

   Policies typically also express a precedence among results (for
   example, an "invalid" attestation result overriding an otherwise
   "valid" bearer-token result) and joint requirements (for example,
   requiring two specific types to be jointly "valid" for a high-risk
   operation).  The information needed to express these, result status
   per type and the Decision Context, is available to the policy by
   construction.

5.5.  Function Placement

   The five functions can be performed entirely within the relying
   party; by a gateway or agent platform on behalf of several relying
   parties; or partly by a dedicated service, for example one that
   performs only type identification and verifier determination and
   returns the determinations to the relying party, or one that also
   performs verification and returns Verification Results.  These are
   deployment choices.  Wherever a function is performed by a party
   other than the relying party, the relying party relies on that
   party's output, and the granularity of that output (a verifier
   determination, a set of results, or a final decision) determines how
   much authority is delegated; the interface between them carries the
   same information defined in this section.

6.  Privacy Considerations

   A credential set reveals the Presenting Entity's relationships across
   trust domains: which issuers it has credentials from, which tenants
   and devices are involved.  Carrying a credential by value exposes its
   contents to every party that processes the set, while carrying it by
   reference (Section 5.1) exposes only metadata, at the cost of an
   additional retrieval interaction; the reference form is preferable
   when a processing party other than the relying party need not see
   credential contents.  A verifier generally does not need the full
   request context to verify a single credential, and the Decision
   Context (Section 5.4) is therefore kept separate from the material
   handed to individual verifiers.

Jiang, et al.           Expires 25 December 2026               [Page 11]
Internet-Draft    Heterogeneous Credential Verification        June 2026

7.  Security Considerations

   The considerations below identify the security properties on which
   the mechanism depends.

   *Credential stripping and downgrade.* An on-path party may remove
   high-assurance credentials from a credential set so that the decision
   is made on weaker credentials alone.  Without a tamper-evident
   enumeration of the presented set (Section 4, Paragraph 2, Item 1), a
   relying party cannot distinguish "not presented" from "stripped".

   *Verifier misrouting.* Redirecting a credential type to an attacker-
   controlled verifier defeats all downstream policy; where verifier
   determination relies on dynamic discovery, the discovered verifier
   needs to be authenticated against trust anchors appropriate to its
   class, not merely at the transport layer.

   *Trust in delegated functions.* Wherever a function of Section 5.5 is
   performed by a party other than the relying party, that party's
   output becomes an attack target, and its binding to the specific
   request determines exposure to replay.

   *Indeterminate results.* Collapsing indeterminate outcomes into
   "valid" is the most likely failure mode in multi-credential systems,
   and the consequences scale with the risk of the request.  Privacy
   properties of the credential set are discussed in Section 6.

8.  IANA Considerations

   This version requests no IANA actions.  A future version may request
   a registry of credential type identifiers (used in the type field of
   a Credential Entry and the credential-type field of a Verification
   Result) and a registry of handling decision outcomes, should the
   working group find a common vocabulary for these useful for
   interoperability.  Whether these registries are warranted, and their
   allocation policies, are open questions for the working group.

9.  Informative References

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

Jiang, et al.           Expires 25 December 2026               [Page 12]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/info/rfc7662>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/info/rfc9334>.

   [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
              DOI 10.17487/RFC9711, April 2025,
              <https://www.rfc-editor.org/info/rfc9711>.

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-wimse-arch-07, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-07>.

   [I-D.ietf-wimse-workload-creds]
              Campbell, B., Salowey, J. A., Schwenkschuster, A.,
              Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
              Credentials", Work in Progress, Internet-Draft, draft-
              ietf-wimse-workload-creds-01, 5 May 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              workload-creds-01>.

   [I-D.ietf-wimse-wpt]
              Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
              Token", Work in Progress, Internet-Draft, draft-ietf-
              wimse-wpt-01, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              wpt-01>.

   [W3C.VC]   W3C, "Verifiable Credentials Data Model v2.0", 2025,
              <https://www.w3.org/TR/vc-data-model-2.0/>.

Jiang, et al.           Expires 25 December 2026               [Page 13]
Internet-Draft    Heterogeneous Credential Verification        June 2026

Appendix A.  Worked Example

   This appendix walks through one concrete scenario to show how the
   information defined in Section 5 fits together.  The JSON-like
   encodings below illustrate the information carried; the concrete wire
   encoding and field names are left for working group discussion
   (Section 5.1).

   An AI agent invokes a high-risk tool through a gateway.  The request
   carries three artifacts: a WIMSE Workload Identity Token
   [I-D.ietf-wimse-workload-creds] identifying the agent workload (by
   value), a user-delegated OAuth 2.0 access token (by reference,
   suitable for introspection), and platform attestation evidence
   carried as an Entity Attestation Token [RFC9711] for the agent's
   execution environment (by reference).

   The credential set, enumerated and bound to the request:

   {
     "request-binding": "sha-256:5b41f0...",
     "set-digest": "sha-256:9d80c2...",
     "entries": [
       {
         "type": "wimse-wit",
         "conveyance": "value",
         "credential": "eyJhbGciOiJFUzI1NiIs..."
       },
       {
         "type": "oauth2-access-token",
         "conveyance": "reference",
         "reference": {
           "token-hint": "ZGVsZWdhdGlvbi0w...",
           "issuer-hint": "https://as.example"
         }
       },
       {
         "type": "eat-evidence",
         "conveyance": "reference",
         "reference": {
           "evidence-handle": "urn:example:evidence:7c2a"
         }
       }
     ]
   }

Jiang, et al.           Expires 25 December 2026               [Page 14]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   Here "set-digest", computed over the enumerated entries and combined
   with "request-binding", lets the receiver detect that an entry was
   added, removed, or substituted; if the agent signs "set-digest", a
   stripped credential becomes detectable rather than indistinguishable
   from one never presented.

   The receiver determines a verifier per entry: the WIT is verified
   locally against the issuing trust domain's keys, the access token is
   introspected at the issuing authorization server, and the evidence is
   appraised by the attestation verifier associated with the evidence's
   trust anchor.  Suppose the attestation verifier is unreachable.  The
   three Verification Results:

   [
     {
       "credential-type": "wimse-wit",
       "status": "valid",
       "verifier": "local:wit-validator",
       "produced-at": "2026-06-11T09:30:05Z",
       "fresh-until": "2026-06-11T09:40:05Z"
     },
     {
       "credential-type": "oauth2-access-token",
       "status": "valid",
       "verifier": "https://as.example/introspect",
       "produced-at": "2026-06-11T09:30:06Z",
       "fresh-until": "2026-06-11T09:32:06Z"
     },
     {
       "credential-type": "eat-evidence",
       "status": "indeterminate",
       "reason": "verifier-unreachable",
       "verifier": "https://rats.example/appraise",
       "produced-at": "2026-06-11T09:30:08Z"
     }
   ]

   The decision policy evaluates the results against the Decision
   Context:

Jiang, et al.           Expires 25 December 2026               [Page 15]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   {
     "request-type": "tool-invocation",
     "risk-level": "high",
     "expected-types": [
       "wimse-wit",
       "oauth2-access-token",
       "eat-evidence"
     ]
   }

   Because the request is classified high risk and the attestation
   result is indeterminate, the policy does not allow the request (see
   Section 5.4); nor does it simply deny, since the two other results
   are valid and fresh.  The outcome is "step-up": the gateway asks the
   agent to re-present attestation evidence, illustrating a handling
   decision beyond binary allow/deny as discussed in Section 5.4.

Acknowledgments

   TODO.

Authors' Addresses

   Yuning Jiang
   Huawei
   Email: jiangyuning2@h-partners.com

   Donghui Wang
   Huawei
   Email: wangdonghui124@huawei.com

   Yurong Song
   Huawei
   Email: songyurong1@huawei.com

   Faye Liu
   Huawei
   Email: liufei19@huawei.com

Jiang, et al.           Expires 25 December 2026               [Page 16]