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

WIMSE                                                           Y. Jiang
Internet-Draft                                                   D. Wang
Intended status: Standards Track                                 Y. Song
Expires: 1 January 2027                                           F. Liu
                                                                  Huawei
                                                            30 June 2026

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

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, or platform-specific API keys.
   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 1 January 2027                 [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 1 January 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.
   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 . . . .   5
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Heterogeneous Credential Verification Mechanism . . . . . . .   6
     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 . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Worked Example . . . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Jiang, et al.            Expires 1 January 2027                 [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 often
   appears together with other credentials or security-context
   artifacts.  The receiving side therefore has to process not only a
   single workload credential, but a set of artifacts associated with
   the same request.

   This situation is common in agentic and workload deployments.  For
   example, an AI agent invoking a tool, a service, or another agent may
   present a workload or agent identity credential, a user-delegated
   OAuth access token [RFC6749], a task-scoped capability or
   authorization token, a Verifiable Presentation [W3C.VC], an X.509
   certificate [RFC5280], or a deployment-specific API key.  These
   artifacts can be issued by different authorities, use different
   formats, be checked by different verifiers, and carry different
   validity, freshness, and assurance semantics.

   Existing specifications generally define how to validate one
   credential family at a time.  They do not define a common receiving-
   side model for the case where several credential families are
   presented with the same request.  In particular, a relying party
   still needs to know how the credential set is represented and bound
   to the request, how each item is typed, how the applicable verifier
   or verifier class is determined, how verifier-specific responses are
   projected into a common Verification Result, and how multiple results
   are combined into one request-handling decision.

   This document defines a mechanism for that set-level processing.  The
   mechanism specifies the information elements and processing steps for
   credential-set representation (Section 5.1), credential type
   identification and verifier determination (Section 5.2), a minimal
   common Verification Result model (Section 5.3), and multi-result
   decision policy (Section 5.4).  It is not tied to a single deployment
   topology: the same functions can be implemented inside a relying
   party, in a gateway serving multiple relying parties, or with
   assistance from a dedicated service (Section 5.5).

   The intended engineering benefit is to decouple request-handling
   policy from credential-specific verifier interfaces.  A request-bound
   credential set helps detect stripping or substitution.  Verifier
   determination prevents unrecognized credentials from being silently
   ignored.  A common Verification Result model gives the relying party

Jiang, et al.            Expires 1 January 2027                 [Page 3]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   a stable input across different verifier families, including explicit
   invalid and indeterminate outcomes.  A common decision input and
   outcome vocabulary makes cross-credential policy easier to implement,
   audit, and reuse across WIMSE deployments.

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, platform API key.

   Verifier:  An entity capable of producing a verification result for
      one or more credential types.  Examples: an OAuth authorization
      server's introspection endpoint [RFC7662], a PKIX path validation
      service, a Verifiable Credential verifier.

   Verifier Class:  A class of verifiers sharing a verification
      capability (e.g., "token introspection endpoint", "PKIX path
      validator"), 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.

Jiang, et al.            Expires 1 January 2027                 [Page 4]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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 an X.509 client certificate presented at the transport
   layer.  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, and one or more task-scoped
   capability tokens.  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.

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.

Jiang, et al.            Expires 1 January 2027                 [Page 5]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   *  *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], an X.509 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.

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

Jiang, et al.            Expires 1 January 2027                 [Page 6]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   +------------+  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)  | | (WIT/WIC)| | (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:

   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.

Jiang, et al.            Expires 1 January 2027                 [Page 7]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   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
      credential 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
   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", "PKIX path validator", "Verifiable
      Credential verifier") that is resolved to a concrete instance by
      configuration, by discovery such as authorization server metadata

Jiang, et al.            Expires 1 January 2027                 [Page 8]
Internet-Draft    Heterogeneous Credential Verification        June 2026

      [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], 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.

   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; a certificate revocation check may carry a
      short bound, an introspection result 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.

Jiang, et al.            Expires 1 January 2027                 [Page 9]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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.

   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" certificate path 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.

Jiang, et al.            Expires 1 January 2027                [Page 10]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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.

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.

Jiang, et al.            Expires 1 January 2027                [Page 11]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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

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

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)

Jiang, et al.            Expires 1 January 2027                [Page 12]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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

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 a W3C Verifiable Presentation
   [W3C.VC] conveying an attribute credential issued in a third trust
   domain (by reference).

   The credential set, enumerated and bound to the request:

Jiang, et al.            Expires 1 January 2027                [Page 13]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   {
     "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": "w3c-verifiable-presentation",
         "conveyance": "reference",
         "reference": {
           "presentation-handle": "urn:example:vp:7c2a"
         }
       }
     ]
   }

   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
   presentation is verified by the Verifiable Credential verifier for
   its issuing trust domain.  Suppose that verifier is unreachable.  The
   three Verification Results:

Jiang, et al.            Expires 1 January 2027                [Page 14]
Internet-Draft    Heterogeneous Credential Verification        June 2026

   [
     {
       "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": "w3c-verifiable-presentation",
       "status": "indeterminate",
       "reason": "verifier-unreachable",
       "verifier": "https://vc.example/verify",
       "produced-at": "2026-06-11T09:30:08Z"
     }
   ]

   The decision policy evaluates the results against the Decision
   Context:

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

   Because the request is classified high risk and the presentation
   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 the Verifiable Presentation, illustrating a
   handling decision beyond binary allow/deny as discussed in
   Section 5.4.

Jiang, et al.            Expires 1 January 2027                [Page 15]
Internet-Draft    Heterogeneous Credential Verification        June 2026

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 1 January 2027                [Page 16]