Internet-Draft	Agent Principal Inputs	November 2026
McGuinness	Expires 15 May 2027	[Page]

Workgroup:: Web Authorization Protocol
Internet-Draft:: draft-mcguinness-oauth-governed-agent-inputs-latest
Published:: 11 November 2026
Intended Status:: Standards Track
Expires:: 15 May 2027
Author:: K. McGuinness

Independent

Agent Resolution Inputs for Agent Principal Federation

Abstract

This document defines optional agent-resolution input profiles for the OAuth 2.0 Profile for Agent Principal Federation, with which an enterprise identity provider resolves an authenticated client or workload identity to an enterprise-governed Agent Principal. The inputs are SPIFFE JWT-SVIDs, WIT-SVIDs, and X.509-SVIDs, and OAuth Attestation-Based Client Authentication, including resolution of managed installations by client instance identifier. Each profile satisfies the federation profile's agent-resolution input contract and is claimed separately.¶

About This Document

This note is to be removed before publishing as an RFC.¶

The latest revision of this draft can be found at https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-inputs.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-oauth-governed-agent-inputs/.¶

Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.¶

Source for this draft and an issue tracker can be found at https://github.com/mcguinness/agent-principal-profiles.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 May 2027.¶

Copyright Notice

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

▲

1. Introduction

[FEDERATION] resolves an authenticated OAuth client or workload identity to a governed Agent Principal through an Identity Binding. It defines the agent-resolution input contract, two inputs (dedicated-client identity and the existing platform JWT), and the issuance, redemption, and resource processing that every input shares.¶

This document defines further inputs: SPIFFE JWT-SVIDs, Client Attestation, including resolution of a managed installation behind a shared client, and SPIFFE WIT-SVIDs and X.509-SVIDs. Each satisfies the input contract of [FEDERATION], resolves from authentication context with actor-token parameters omitted, and requires trusted configuration. An implementation that claims none of these inputs does not need this document.¶

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.¶

Agent Principal, Identity Binding, Client Association, credential class, Governance Tenant, Target Tenant, issuer-bound presenter key, and grant proof key follow [FEDERATION]. Client Attestation terminology follows [ATTEST].¶

2. Conformance

The following inputs are OPTIONAL: SPIFFE JWT-SVID (Section 4), Client Attestation (Section 5), and SPIFFE WIT-SVID and X.509-SVID (Section 6).¶

For each input it claims, the IdP, RAS, and client MUST implement their respective requirements for that input in this document together with [FEDERATION]. Conformance claims under [FEDERATION] name each supported input of this document.¶

Each input of this document resolves from authentication context, with actor-token parameters omitted ("Agent Resolution Input Validation" in [FEDERATION]). The JWT-SVID, WIT-SVID, and Client Attestation inputs apply to delegated and self-acting access. A client authenticated by X.509-SVID presents no JWT to repeat as the self-acting subject token, so the X.509-SVID input applies to delegated access only ("Self-Acting Issuance: WAG" in [FEDERATION]).¶

3. Common Rules for These Inputs

3.1. Qualified Identities

Table 1: Agent-resolution inputs and qualified identities
Input	Qualified identity	Reference
SPIFFE JWT-SVID	Approved trust domain and exact SPIFFE ID in `sub`	Section 4
SPIFFE WIT-SVID	Approved trust domain and exact SPIFFE ID in the validated `sub`	Section 6
SPIFFE X.509-SVID	Approved trust domain and exact SPIFFE ID in the certificate's URI Subject Alternative Name	Section 6
Client Attestation	Trusted attester and validated `sub`; for a managed installation, also the IdP Receiver Scope and `client_instance_id`	Section 5

For Client Attestation, sub identifies the OAuth client, and the client-to-agent mapping is explicit.¶

An approved trust domain is a SPIFFE trust domain that a server's configuration trusts, with the source of its bundle: at the IdP, for an input; at a RAS, for JWT-SVID client authentication (Section 4). The source is a bundle or bundle endpoint configured as Section 6 of [SPIFFE-OAUTH] describes, or, for one client only, that client's Client ID Metadata Document (Section 3.2).¶

3.2. Trust Bundles from Client Metadata

A server selects the bundle that validates SVIDs from a client whose metadata is a Client ID Metadata Document as follows: the IdP for the SPIFFE inputs, and a RAS for JWT-SVID client authentication.¶

A server configured with a bundle or bundle endpoint for the trust domain of the document's spiffe_id, as Section 6 of [SPIFFE-OAUTH] describes, MUST validate with that bundle and MUST ignore the document's spiffe_bundle_endpoint, so a document cannot supply keys for a trust domain the server already trusts through its own configuration. A bundle obtained from any Client ID Metadata Document, this client's or another's, is not so configured. This narrows Section 6.1 of [SPIFFE-OAUTH], which recommends that preference.¶
Otherwise, a server configured to do so for the client MAY validate SVIDs with a bundle it obtains from the document's spiffe_bundle_endpoint only when the trust domain of the document's spiffe_id equals, or is a subdomain of, the host of the client's client_id URL (Section 8.2 of [SPIFFE-OAUTH]). It then uses the bundle only for SVIDs presented to authenticate as that client (Section 6.1 of [SPIFFE-OAUTH]). At the IdP, a SPIFFE ID validated with it resolves an agent only through an Identity Binding configured for that client.¶
Otherwise, the server ignores the document's spiffe_bundle_endpoint, and the document establishes no approved trust domain. A server that accepts no bundles from documents is a deployment that does not accept that trust model, which Section 8.2 of [SPIFFE-OAUTH] requires to ignore them.¶

3.3. Grant Lifetime

Under the grant lifetime rule ("Common Grant Claims, Lifetime, and Response" in [FEDERATION]), these inputs bound the grant as follows:¶

Table 2: Grant lifetime bound by input
Input	Lifetime bound on the grant
JWT-SVID	Its `exp`
WIT-SVID and Client Attestation	The credential's `exp`; the PoP JWT adds no limit
X.509-SVID	The earliest `notAfter` in the validated certificate path, excluding the trust anchor

3.4. Algorithms

Implementations that support the JWT-SVID input, including a RAS that accepts JWT-SVID client authentication ("Client Authentication and Algorithms" in [FEDERATION]), MUST support this capability in addition to those of [FEDERATION]:¶

Table 3: Mandatory-to-implement algorithm for JWT-SVIDs
Artifact	Mandatory-to-implement (MTI) capability
JWT-SVID, where supported	Validation at the IdP or the RAS: `RS256` and `ES256`, both required by this profile; [SPIFFE-OAUTH] requires no algorithm

4. SPIFFE JWT-SVID

This OPTIONAL input identifies workloads independently of the OAuth client identifier, including multiple agents behind a shared client. JWT-SVID client authentication at either the IdP or the RAS follows this section. At the RAS it authenticates the client only: the RAS takes the Agent Principal from the grant ("Agent Principal Correlation" in [FEDERATION]), and the validated SPIFFE ID, like a client identifier, does not replace it.¶

Presentation: Client authentication by client_assertion with client_assertion_type urn:ietf:params:oauth:client-assertion-type:jwt-spiffe.¶
Validation: The server MUST apply Section 3.2 of [SPIFFE-OAUTH], including the assertion type and the client identification of Section 3.1 of [SPIFFE-OAUTH], and Section 5 of [SPIFFE-OAUTH] and Section 6 of [SPIFFE-OAUTH] for trust establishment and key distribution. It MUST also verify the signature with keys authorized for the SPIFFE ID's trust domain. The IdP MUST do both before resolving the agent. An optional iss MUST NOT select another trust domain or key authority.¶
Resolution: The IdP MUST resolve the exact SPIFFE ID in the validated sub through an Identity Binding ("Identity Binding" in [FEDERATION]). The SPIFFE ID's association with the authenticated client is an authentication check, not an Identity Binding or Client Association.¶
Proof: A JWT-SVID is bearer evidence: DPoP, when used, binds the issued grant to the grant proof key, not the JWT-SVID to its presenter. A policy requiring issuer-bound presenter proof MUST reject this input rather than treat DPoP as that proof ("Bearer Evidence Limits" in [FEDERATION]).¶

5. Client Attestation

This OPTIONAL input maps the attested OAuth client identity explicitly to one Agent Principal. It relies on a trusted attester's attestation of the client identity and confirmation key, not a registered client key. It establishes runtime or workload provenance only as far as verified attestation claims and the attester's trusted issuance policy support. It does not distinguish agents behind a shared client, except through the managed-installation binding below. Otherwise those agents need distinct workload evidence, such as a JWT-SVID or platform JWT.¶

Presentation: Client authentication with the configured [ATTEST] method.¶
Validation: The IdP MUST validate the attestation and proof under [ATTEST] before resolving the agent. It MUST identify the attester unambiguously from the trusted verification key and configured attester-to-client associations. An iss, when present, MUST match that attester.¶
Attester endorsement: The IdP MAY derive the attester-to-client association from an endorsement it accepts under Section 2.1 of [ATTESTER-ENDORSEMENT]. An endorsement MUST NOT create or change an Identity Binding or Client Association. Because the binding names the attester, a newly endorsed attester resolves no Agent Principal until an Identity Binding names it. An endorsement accepted under that policy is not client metadata acting by itself ("Authentication, Resolution, and Proof" in [FEDERATION]).¶
Resolution: The IdP MUST resolve the trusted attester and the validated sub through an approved Identity Binding ("Identity Binding" in [FEDERATION]).¶
Managed installation: Where agents share one OAuth client, a Client Attestation carrying client_instance_id under [INSTANCE] MAY resolve the agent instead. The IdP MUST accept it only from an attester configured to assign that identifier at Installation granularity (Section 1.1 of [INSTANCE]) under the continuity rules of Section 6 of [INSTANCE]. The Identity Binding names the exact attester, client (sub), IdP Receiver Scope, and client_instance_id. Trusted configuration for the client selects client-level or installation-level resolution. Attestation claims MUST NOT select the level, and a failed match MUST NOT fall back to the other level. A new enrollment yields a new identifier that needs its own approved Identity Binding. The IdP MUST NOT infer continuity across identifiers or attesters.¶
Proof: With attest_jwt_client_auth, any grant proof key MUST match the attestation's confirmation key. This narrows the allowance in Section 5.2 of [ATTEST] for a separate DPoP key. With attest_jwt_client_auth_dpop, one DPoP proof serves both roles. Key retention follows Section 7.1, and Section 7.2 covers instance keys at the RAS.¶

6. SPIFFE WIT-SVID and X.509-SVID Resolution

These OPTIONAL inputs resolve the SPIFFE ID validated during OAuth client authentication for this token request, in the SVID class that the client and IdP configure. General non-SPIFFE Workload Identity Token (WIT) and Workload Identity Certificate (WIC) inputs of [WIT] are excluded ("Excluded Compositions" in [FEDERATION]). One shared SPIFFE ID cannot distinguish independently governed agents. Either input proves control of a credential-bound key. Assurance about a particular runtime or execution depends on the credential authority's issuance rules and identity granularity. Appendix A.3 illustrates both inputs.¶

6.1. WIT-SVID

Presentation: The WIT-SVID in OAuth-Client-Attestation, with its proof in OAuth-Client-Attestation-PoP.¶
Validation: The IdP MUST apply Section 3.4 of [SPIFFE-OAUTH] and [WIT], including their client-identifier association, trust, validity, and proof requirements. It MUST require typ=wit+jwt. It MUST validate possession of the key in cnf.jwk through the Client Attestation PoP JWT. A WIT-SVID MUST NOT be accepted as bearer evidence. Its optional iss MUST NOT select a different trust domain or key authority.¶
Resolution: The IdP MUST resolve the approved trust domain and exact SPIFFE ID in the validated sub through an Identity Binding ("Identity Binding" in [FEDERATION]).¶
Proof: When DPoP is used at issuance, its key MUST match the WIT-SVID's cnf.jwk. The IdP MUST compare the JWK thumbprints of the DPoP key and cnf.jwk as used in [RFC9449] and MUST reject a mismatch with invalid_request. This narrows Section 5.2 of [ATTEST], under which a DPoP key used alongside the Client Attestation PoP JWT need not match the attestation's cnf key. This carries the WIT-endorsed key into the grant binding; the Client Attestation PoP JWT remains required. Key retention follows Section 7.1.¶

6.2. X.509-SVID

Presentation: The client certificate on the mutual-TLS connection carrying the token request.¶
Validation: The IdP MUST apply Section 3.3 of [SPIFFE-OAUTH], which profiles [RFC8705], to the certificate and proof established by mutual TLS for this request. This includes its client identification (Section 3.1 of [SPIFFE-OAUTH]), trust, validity, and proof requirements. A certificate supplied only in a request parameter or an untrusted forwarding header MUST NOT establish the workload identity, and the request then fails client authentication. TLS termination follows Section 6.5 of [RFC8705].¶
Resolution: The IdP MUST resolve the approved trust domain and exact SPIFFE ID in the certificate's URI Subject Alternative Name through an Identity Binding ("Identity Binding" in [FEDERATION]).¶
Proof: A DPoP grant proof key, when required, is proven on the same token request. It MAY differ from the certificate key, because mutual TLS can terminate separately from the component generating DPoP proofs. The certificate does not endorse the DPoP key; the authenticated request associates it with this issuance, and the grant uses cnf.jkt, not certificate confirmation.¶

7. Implementation Considerations

These considerations add no requirements. They describe key handling that decides whether bound grants and tokens remain usable.¶

7.1. Resolution-Key Lifecycle

The resolution key is the key whose possession an input proves: the cnf.jwk of a WIT-SVID or the confirmation key of a Client Attestation, or the key of an X.509-SVID certificate. When the resolution key is also the grant proof key, replacing it does not rebind an outstanding grant, access token, or refresh token. This is the case for WIT-SVID or Client Attestation when DPoP is used. Continued use requires retaining the corresponding proof key. Otherwise, the client obtains a new grant with the replacement key and new RAS authorization. Any subject-credential binding still applies and may require a new subject credential. Grant key transition is not defined ("Excluded Compositions" in [FEDERATION]).¶

7.2. Instance Keys at the RAS

With [INSTANCE], instance keys differ per receiver scope (Section 4.1 of [INSTANCE]). A bound grant carries the IdP-scoped key. A client that also authenticates to the RAS with a Client Attestation therefore uses attest_jwt_client_auth there and proves the grant key with a separate DPoP proof, unless the IdP and RAS share a receiver scope.¶

8. Security Considerations

The security considerations of [FEDERATION] apply, including its bearer evidence limits. In the JWT-SVID path, the same bearer credential also satisfies client authentication, so that check is not an independent possession factor.¶

Managed-installation resolution relies on the attester's continuity evidence and enrollment controls (Section 9 of [INSTANCE]).¶

9. Privacy Considerations

The privacy considerations of [FEDERATION] apply. Client instance identifiers are scoped per receiver under Section 10 of [INSTANCE].¶

10. IANA Considerations

This document has no IANA actions.¶

11. Normative References

[FEDERATION]: McGuinness, K., "OAuth 2.0 Profile for Agent Principal Federation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-governed-agent-federation, 9 October 2026, <https://mcguinness.github.io/agent-principal-profiles/draft-mcguinness-oauth-governed-agent-federation.html>.
[ATTEST]: Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-12, 12 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-12>.
[ATTESTER-ENDORSEMENT]: McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-01>.
[INSTANCE]: McGuinness, K., "OAuth 2.0 Client Instance Identifiers", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-01>.
[RFC8705]: Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.
[RFC9449]: Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[SPIFFE-OAUTH]: Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-03, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-03>.
[WIT]: 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-03, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-03>.
[BCP14]: Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Appendix A. Input Variants

These non-normative variants change only the agent-resolution input of the dedicated-client walkthrough in [FEDERATION]; the message sequence is unchanged. The resulting actor is always the IdP issuer and agent-42.¶

Table 4: Input variants relative to the dedicated-client walkthrough
Variant	Authentication and presentation	Identity resolved
Shared client with JWT-SVID	JWT-SVID as `client_assertion`, with `client_assertion_type` `jwt-spiffe`	Approved trust domain and exact SPIFFE ID in `sub` (Section 4)
WIT-SVID	`spiffe_wit`: WIT-SVID in `OAuth-Client-Attestation`, with a fresh PoP header signed by its key	Exact SPIFFE ID in the validated `sub` (Section 6)
X.509-SVID	`spiffe_x509`: mutual-TLS authentication with the X.509-SVID	Exact URI Subject Alternative Name (Section 6)

The JWT-SVID variant uses IdP client_id platform-sso. The WIT-SVID and X.509-SVID variants use the SPIFFE ID as client_id. Across the variants:¶

Proof key: In the bound profile, K signs the issuance DPoP proof, except that the WIT-SVID variant uses the WIT-SVID key. The X.509-SVID variant's DPoP key may differ from its TLS key.¶
Lifetime: The input bounds the grant lifetime under Section 3.3.¶
Client Association: Each variant needs a Client Association for its authenticated client. The JWT-SVID variant needs a separate one for platform-sso. In the WIT-SVID and X.509-SVID variants, where the authenticated client is the workload itself, the association can be administered together with the binding.¶
Negative tests: The dedicated-client negative tests of [FEDERATION] apply to each binding and to each grant its input supports, except that replay rules follow the input specification.¶

A.1. Identity Mapping Example

Alice asks a data-analysis agent to read a file. The platform uses one shared OAuth client for many agents, so its client identifier alone cannot identify which agent is acting. This non-normative example uses the optional SPIFFE input to make that distinction through four separate decisions:¶

Resolve the agent. The IdP validates the workload's JWT-SVID, and an Identity Binding maps its exact SPIFFE ID, spiffe://platform.example/accounts/acme/agents/workload-7, to agent-42 in the namespace of https://idp.example/, in Governance Tenant acme.¶
Authorize the client. The SPIFFE ID's registration with the client (Section 3.1 of [SPIFFE-OAUTH]) authenticates the caller as platform-sso, and a separate Client Association permits that client to use this binding for delegated ID-JAG issuance.¶
Authorize delegation. Alice's ID Token, issued for platform-sso, identifies her as alice-app. The IdP authorizes agent-42 to act for her with files.read at the requested resource in Target Tenant acme-data and issues an ID-JAG.¶
Apply resource policy. The RAS resolves Alice to local user user-108 and correlates the agent with local principal service-principal-42. Alice has the file permission, and resource policy permits this agent to act for her; the agent needs no file permission of its own.¶

Table 5: Identity claims across the domain boundary
Claim	ID-JAG issued by IdP	Access token issued by RAS
`sub` (Alice)	`alice-ras`	`user-108`
`act.iss` (agent namespace)	`https://idp.example/`	`https://idp.example/`
`act.sub` (Agent Principal)	`agent-42`	`agent-42`
`client_id` (client at RAS)	`platform-api`	`platform-api`
`scope`	`files.read`	`files.read`

The RAS translates the user and preserves the agent:¶

alice-ras is Alice's identifier in the target SSO namespace.¶
platform-api is the registration corresponding to platform-sso at the RAS.¶
The local agent record service-principal-42 supports authorization but does not replace act.sub.¶

A.2. Shared Platform Client with SPIFFE

This variant completes Appendix A.1. The workload obtains a JWT-SVID with the IdP issuer as its audience. The existing SPIFFE format omits iss and iat, and the expiration is an illustrative NumericDate value. The IdP selects trusted signing keys from its configured bundle for the platform.example trust domain.¶

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "spiffe-key-1"
}

{
  "sub": "spiffe://platform.example/accounts/acme/agents/workload-7",
  "aud": ["https://idp.example/"],
  "exp": 1789647063
}

The JWT-SVID authenticates the client through the configured SPIFFE association and resolves the agent separately. It is bearer evidence and does not attest that grant proof key K belongs to the workload. platform-api replaces analysis-api in grants, access tokens, and RAS client authentication.¶

A.3. WIT-SVID and X.509-SVID

Both variants resolve the workload authenticated on the exchange request through an exact Identity Binding from spiffe://platform.example/agents/analysis to agent-42. The user ID Token is issued to that authenticated client, not reused from analysis-client. The WIT-SVID carries the SPIFFE ID in sub and the workload public key in cnf.jwk. For X.509-SVID, mutual-TLS authentication replaces the two attestation headers. An authoritative association supplies the downstream client identifier in both cases.¶

Appendix B. Document History

RFC Editor: Remove this section before publication.¶

Initial version.¶

Author's Address

Karl McGuinness

Independent

Email: public@karlmcguinness.com