A trusted signature answers a narrow question: did an accepted signing authority authenticate this token’s contents? It does not answer whether this token type belongs at this endpoint, whether its subject is eligible for exchange, or whether the requested target should trust the resulting authority.

Build explicit token-processing contracts

Use separate input contracts for human subject evidence and agent actor evidence. For JWT inputs, establish allowed issuers, issuer-associated verification keys, algorithms, expected profile, intended audience, required claims, and temporal rules. Do not select trust using an arbitrary key URL from the submitted token. JWT security guidance stresses algorithm verification, issuer/audience validation, and mutually exclusive rules where different token kinds could otherwise be confused.

An actor JWT-SVID and a human access token may both be signed JWTs, but they are not interchangeable. A user JWT should not satisfy the agent processor because it has a sub field. A workload credential should not become a human subject merely because its signature verifies.

IdP configuration review

Review the actual subject processor, actor processor, exchange policy, access token manager, and OAuth client configuration together. Verify the installed release’s behavior and extension capabilities. This guide does not prescribe unverified administrator UI paths or claim that all task constraints are natively implemented in an access token manager.

Verified input	Policy decision	Output
User issuer and stable subject	Eligible user and tenant	Issuer-qualified user subject mapping
Actor issuer, SPIFFE subject, intended audience	Approved agent identity	act.sub from verified actor evidence
Authenticated OAuth client	Permitted client/actor relationship	client_id under issuer control
Requested audience/resource	Allowed exchange edge	Approved target audience
Requested scopes	Allowed operations and delegation limits	Granted scopes, never blind copying
Protected approval record	Task/resources still approved	Reference or enforced task constraints

 

An illustrative policy contract

accept actor evidence only from configured agents.example.org authority
map verified SPIFFE subject → current actor
require approved (client, actor, user, tenant) relationship
permit exchange only to reviewed resource identifiers
grant permissions within subject rights AND delegation constraints
require current approval for high-impact tasks
reject caller-provided actor overrides
record policy decision and output token identifier

Input audiences and output validation

An exchange can legitimately transform a credential intended for one context into authority for another. Therefore, define which input contexts the STS accepts and which output targets each exchange relationship permits. Do not accept arbitrary audiences simply because the token was issued by a trusted issuer. Do not assume an API-only token is automatically an eligible exchange credential.

Resource servers must independently validate the issued access token. If using the JWT access-token profile, RFC 9068 supplies recipient validation requirements, including token typing and audience checks. An opaque-token deployment instead depends on its agreed introspection profile. Neither approach removes application authorization.

The act claim records delegated actor attribution. may_act expresses actor eligibility, not universal permission or task approval. A submitted actor name must never override the identity obtained from verified evidence.

Review evidence

• Export effective configuration, not only screenshots of one processor.
• Demonstrate rejection of cross-profile tokens and unauthorized audience transitions.
• Test omitted, malformed, and unexpected actor claims.
• Verify scopes are granted by policy rather than echoed from requests.
• Identify which component enforces resource-level and approval-level restrictions.

Takeaway: verification, mapping, and authorization are separate operations. Each requires a testable contract.