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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [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, . [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, . [W3C.VC] W3C, "Verifiable Credentials Data Model v2.0", 2025, . 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]