PingFederate · Attestation-Based Client Authentication

Autonomous agents and workloads increasingly act — call APIs, move money, make decisions — with no human in the loop for each request. That breaks the assumptions behind a hand-issued client_id + secret. Four gaps, in particular:

Everything below is one coherent answer to those four: a federated trust spine, a two-tier identity, live authorization, and fine-grained delegated grants.

A trust anchor vouches for agent types. Each type is deployed as many instances. An instance authenticates to the authorization server, which resolves it back up the chain to the anchor — live — before issuing a token. Withdraw a type at the anchor and every instance of it is denied at once.

A token is issued only if both phases pass. Authentication proves possession; authorization proves standing. They're independent — a perfectly-signed request from a revoked type still fails.

Phase ① is the client-authentication draft; phase ② is OpenID Federation resolution + policy. Revocation lives entirely in phase ② — which is why it bites on the very next call.

We use Rich Authorization Requests (authorization_details, RFC 9396) — but in a specific way worth calling out, because it inverts where the details come from and where they bite.

The authorization_details ride inside the client attestation, signed by the attester. They aren't something the client asks for and a user consents to — they're an explicit, attester-vouched entitlement the client already holds, and the AS applies them as a ceiling on the grant at issuance. RAR becomes an extension / profile of the attestation, not a request on the wire.

Concretely, the attestation carries authorization_details: [{ "type":"sales_agent", "actions":[…], "locations":[…], "sales_regions":["EMEA"], "privileges":[…] }]. The type names the entitlement schema; its fields are the explicit constraint. The attester vouches for it, and the token's authority is granted ⊆ the attested entitlement — an instance filter at the token endpoint, per instance, rather than policy re-evaluated later at each Protected Resource.

Two distinct layers — don't merge them. This attested RAR is the agent's entitlement envelope — what this type is allowed to do. On whose behalf it acts is separate: the act claim (RFC 8693 token exchange) carries the principal → agent actor chain — delegation, never impersonation. One says what the agent may do; the other says whom it does it for.

When an agent platform registers as one OAuth client, a whole fleet of concurrent agent instances collapses into a single client identity — so there's no per-instance policy, no audit attribution, and no way to contain one compromised instance. The AI Agent Instance profile (draft-mcguinness-oauth-ai-agent-instance-00) closes that gap: the Agent Attester mints a distinct, stable, key-independent identity for each instance, and the AS surfaces it — with attestable provenance — in the issued token.

The claims it defines

Two carriers, one identity. The evidence rides either in a Client Instance Assertion or in a Client Attestation (draft-ietf-oauth-attestation-based-client-auth + DPoP). This demo uses the Client Attestation carrier — the exact ② flow decoded below — with the twist that attester trust is resolved via OpenID Federation rather than a bilateral AS↔attester agreement. Either way the access token is sender-constrained and the instance is surfaced in act (delegation) or top-level sub (self-acting), tagged sub_profile: "ai_agent client_instance".

Advertised in metadata. The client registers ai_agent_instance_profile: true (the AS then requires instance evidence on every covered grant); the AS advertises ai_agent_instance_profile_supported: true. Assurance comes in tiers — platform self-attestation, hardware-rooted (agent_runtime EAT), or an independent third-party attester — and policy can condition on which.

The same split, on the wire (example values). The attestation carries the entitlement envelope — what the type may ever do — plus the instance's identity and provenance. A token exchange then mints an access token narrowed to one task, stamped with the actor — the agent instance, named by its agent_instance_id and classified ai_agent per the AI Agent Instance profile (draft-mcguinness-oauth-ai-agent-instance) — and sender-constrained to the instance key.

① Client Attestation — the Agent Instance Evidence, signed by the Agent Attester

{
  "iss": "https://attester.example.com",         // the Agent Attester — vouches for the instance
  "sub": "https://rp.example.com",               // the OAuth client = the Agent Platform (not the identity)
  "agent_instance_id": "https://attester.example.com/instances/sess-9f2c",  // ← THE instance identity — attester-minted, key-independent
  "agent_platform": "urn:example:orchestrator:v5",   // provenance — the runtime it executes under
  "agent_model": { "id": "urn:example:model:atlas", "version": "7.3" },   // provenance — model + version
  "cnf": { "jwk": { "kty":"EC", "crv":"P-256", "x":"…", "y":"…" } },   // binds the instance KEY — binding material, not identity
  "workload": { "attested_by":"spiffe", "spiffe_id":"spiffe://banking.demo/payment-agent" },   // SPIFFE infra identity — provenance
  "authorization_details": [                        // ← the ENTITLEMENT ENVELOPE (the ceiling)
    { "type":"sales_agent",
      "actions":["read_accounts","create_opportunity","submit_quote"],
      "locations":["https://crm.contoso.com/api"],
      "sales_regions":["EMEA"], "privileges":["quota:standard"] } ]
}

Plus a PoP signed by the instance's cnf key (aud = this AS, one-time jti). Together they authenticate the instance under its vouched type — phase ① of the gate. Mind the three roles the draft keeps distinct: agent_instance_id is the identity, cnf is the binding key, and agent_platform / agent_model / workload are provenance.

② Access token — issued by the AS, narrowed + the instance surfaced in act

{
  "iss": "https://as.bank.example",
  "sub": "https://principal.example/alice",      // the PRINCIPAL — on whose behalf
  "act": {                                       // the ACTOR — the agent INSTANCE (delegation)
    "iss": "https://attester.example.com",          //   the Agent Attester that vouched (act.iss)
    "sub": "https://attester.example.com/instances/sess-9f2c",   // = agent_instance_id — the instance, not the key
    "sub_profile": "ai_agent client_instance",      //   classifies the actor as an AI agent instance
    "agent_model": { "id": "urn:example:model:atlas", "version": "7.3" },   // provenance, surfaced per policy
    "cnf": { "jkt": "…" } },                         //   sender-constrained to the instance key
  "client_id": "https://rp.example.com",            // the Agent Platform (the registered client)
  "scope": "create_opportunity",
  "authorization_details": [                        // ⊆ the attested envelope, narrowed to THIS task
    { "type":"sales_agent", "actions":["create_opportunity"],
      "locations":["https://crm.contoso.com/api"], "sales_regions":["EMEA"] } ],
  "cnf": { "jkt": "…" },                             // token sender-constrained to the instance key
  "aud": "https://crm.contoso.com/api"
}

Read the two together. The envelope in ① is the ceiling the attester vouched for; the token in ② is ⊆ that envelope — narrowed to one action for one task. sub is the principal, and act is the agent instance: act.sub is its agent_instance_id, act.iss the Agent Attester that vouched, act.sub_profile classifies it ai_agent client_instance. The action is attributable to this instance acting for the principal — never disguised as the principal (impersonation). cnf binds the token to the instance's key, so a stolen bearer copy is useless.

The trust spine is OpenID Federation 1.0. Every participant is an Entity with a signed statement; trust is a chain of signatures up to a known anchor key — not Web PKI, not TLS certificates, not a shared secret.

The trust chain — leaf → anchor

A chain is an ordered set of statements. Each link's iss equals the next-one-up's sub, and each is signed by a key in the statement above it — so you verify signatures all the way up; the top is the Trust Anchor's own self-signed configuration, whose key you trust out-of-band.

ES[0]  Entity Configuration of the LEAF          — self-signed by the leaf
   ↑  signed by a key in
ES[1]  Subordinate Statement about the leaf      — signed by the superior (vouches)
   ↑  signed by a key in
ES[n]  Entity Configuration of the TRUST ANCHOR  — self-signed · the root of trust

The client can carry the pre-assembled chain in the trust_chain JWS header, or the AS walks authority_hints up to the anchor itself (fetching each Subordinate Statement from the superior's federation_fetch_endpoint). Either way the AS re-verifies every signature up to the anchor.

Metadata policy — the federation shapes what a member may declare

A Subordinate Statement can carry a metadata_policy that applies to the subject and everything below it. Operators — value, add, default, one_of, subset_of, superset_of, essential — let a superior constrain or set a leaf's effective metadata: cap the scopes it may claim (subset_of), force a value, require a field. Ecosystem rules are applied at resolution, without editing any member's own config.

Trust marks — attested status & compliance

A trust mark is a separately-signed JWT (trust-mark+jwt) asserting a member conforms to a profile (e.g. region-emea, workload-inspection). It counts only if its issuer is one the anchor recognises for that type and it validates (signature, expiry, status). So the AS can gate not just on "is it in the federation" but "does it hold these attestations."

In this demo: the OpenID Federation Trust Controller is the Trust Anchor + resolver; a fedhost serves each entity's self-signed configuration; the client presents/resolves its chain at the token endpoint and the AS re-derives it to the anchor live. Revocation = the anchor deletes the leaf's Subordinate Statement → the chain no longer resolves → the very next token fails. That is the ⑤ Revoke step in the Deployment tab.

Every layer is a published specification, so the pieces interoperate and can be verified independently.

Two EC P-256 keys, created in your browser via WebCrypto: the Client Attester (vouches for the app) and the client instance key (the key the app proves possession of; its public JWK goes in the attestation’s cnf).

—

—

An agent identity has two keys at two levels. You register an agent type once — it is a federation entity with its own entity / attester key, enrolled as a subordinate of the trust anchor so it chains into the federation. Then you deploy instances of that type: each instance mints its own local key and is attested by its type. At the token endpoint the instance presents two signatures — one from each key.

Why the split: the type is the unit of trust & revocation — register once, kill the whole fleet by de-registering it; the instance is the unit of possession — each deployment is individually bound and individually revocable. Day 0 below runs this live.

Phase 2 — the instance. Phase 1 got the type a token; this phase is about the instance and how its identity is built — not another token. Deploy an instance of the type: it mints its own local key (the cnf/PoP key), the type / attester key signs a Client Attestation binding that key via cnf (the type vouches for the instance), and the instance key signs the PoP. A SPIFFE agent gives the instance a JWT-SVID whose spiffe_id + attributes ride in the attestation's workload claim as metadata — what / where the workload is — which does not authenticate. The key point: an instance has no standing of its own — it borrows the type's. So revoke the type in Phase 1 and every instance is denied at once (fleet revocation), exactly what the ⑤ Revoke step above demonstrates. Walk the identity through in your browser, then on a real deployed workload.

Walk it through — in your browser

Phase 1 — the type. An agent type is a federation entity. Mint its entity / attester key (the key that will vouch for every instance), self-sign its entity configuration (served at /.well-known/openid-federation), and register it in the trust controller — the anchor signs a subordinate statement binding entity_id → public key, so the type now chains to the anchor. This is the type's key, created once; it is not the per-instance key (that comes in Phase 2). The private key never leaves the entity — here it is generated in your browser; only the public JWK and the signed statement go out. Everything below is live: real keygen, a real registration, a real /resolve.

Pick where the attester key lives, then run it. Your browser mints a SPIFFE SVID and a proof of possession of a fresh instance key, and posts them to /federation/attestation. The two options are the same request to the same endpoint — they differ only in which demo client mints, hence where the signing key lives.

This is the authorization step that follows authentication. The client first authenticates — in the attestation flow above, with its attestation credential; here, with its client_credentials. Based on that authenticated identity, PingFederate then authorizes it by resolving the client's entity record from the trust controller and granting access only if the client is a federation member (chain resolves to the anchor), is within policy, its status is active, and — the crux — the requested scopes are within the scopes registered to its entity. The trust controller does authorization, not authentication. Computed live — /api/authorize → trust controller /resolve.