Heterogeneous Credential Verification for Workload and Agentic Systems

Heterogeneous Credential Verification for Workload and Agentic Systems Huawei

jiangyuning2@h-partners.com

Huawei

wangdonghui124@huawei.com

Huawei

songyurong1@huawei.com

Huawei

liufei19@huawei.com

Security WIMSE Workload Identity AI Agent Credential Verifier Authorization 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.

Introduction The WIMSE Working Group addresses the representation, propagation, and processing of workload identity in multi-system environments , including workload identity credentials and proof-of-possession mechanisms 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 , OAuth 2.0 access tokens , JWTs , X.509 certificates , W3C Verifiable Credentials and Presentations , and further token or context formats such as Entity Attestation Tokens 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. 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 (), it specifies how a heterogeneous credential set is represented (), how each credential's type is identified and its verifier determined (), a minimal common model for verification results (), and a policy model for combining results into a handling decision (). 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 ().

Terminology The terms "workload" and "trust domain" are used as defined in . 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 one or more credential types. Examples: an OAuth authorization server's introspection endpoint , a RATS Verifier , 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.

Use Cases

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.

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.

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.

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

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 , a RATS attestation result , 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.
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.

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; discusses where the functions run.

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.

Each Credential Entry carries:

type:: The credential type (), 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 (), is carried forward as an input to the decision rather than silently ignored.

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 ); 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", "attestation verifier", "PKIX path validator") that is resolved to a concrete instance by configuration, by discovery such as authorization server metadata , 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" () and carries it into the decision. The credential is not dropped.

Verification Result Model Each credential is verified by its determined Verifier using that verifier's native protocol (OAuth introspection , RATS appraisal , 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; 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.

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

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.

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 () 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 () is therefore kept separate from the material handed to individual verifiers.

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 (), 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 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 .

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.

Informative References Verifiable Credentials Data Model v2.0 W3C

Worked Example This appendix walks through one concrete scenario to show how the information defined in fits together. The JSON-like encodings below illustrate the information carried; the concrete wire encoding and field names are left for working group discussion (). An AI agent invokes a high-risk tool through a gateway. The request carries three artifacts: a WIMSE Workload Identity Token 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 for the agent's execution environment (by reference). The credential set, enumerated and bound to the request: 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: The decision policy evaluates the results against the Decision Context: Because the request is classified high risk and the attestation result is indeterminate, the policy does not allow the request (see ); 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 .

Acknowledgments TODO.