Identity element
The Identity element extracts an agent DID from the pipeline at the edge where identity evidence is available. Drop it on the edge that corresponds to the identity slot you want to populate. One surface can hold multiple Identity elements at different edges.
Placement slots
| Edge | Identity slot | What it resolves |
|---|---|---|
| Access Point → Managed Agent (request) | Inbound caller identity | DID of the incoming caller. |
| Access Point → Managed Agent (response) | Protected agent identity | DID of the managed agent responding to the caller. |
| External Target → Managed Agent (response) | External agent identity | DID of the external upstream the managed agent calls out to. |
| Managed Agent → Transit Point (request) | Outbound managed-agent identity | DID of the managed agent for a specific transit point. Used by Workload Binding flows. |
When placed on a Managed Agent → Transit Point edge, only the From Payload (identity metadata) extraction type is available.
Identity Extraction Type
Select the type using the Identity Extraction Type dropdown. Type-specific fields appear below once a type is selected.
| Type | Description |
|---|---|
| From Payload (identity metadata) | Reads identity claims from a named field in the payload body. |
| From API Key | On the inbound caller slot, derives the caller’s DID from the API key the caller presents. On other slots, derives the agent DID from the configured API key. |
| From JWT Claims | Extracts the agent DID from a named claim in the JWT Bearer token. |
| Static DID | Uses a fixed, pre-known DID for all requests. Not currently available: visible but disabled. |
| From mTLS certificate | Derives the agent DID from the client certificate presented during the request. Not currently available: visible but disabled. |
Type: From Payload (identity metadata)
The sidebar panel shows a Configure Fields… button that opens the fullscreen editor. Configure dot-notation field paths and the JSON schema there. The sidebar also shows the current field count.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| Strip raw identity metadata after injection | toggle | No | Off | When on, removes the raw _meta.[field] from the request once the VP credential is injected. Not shown on A2A surfaces. |
Type: From API Key
The fields depend on the slot.
Inbound caller identity slot. The panel has no key picker. It shows “Each caller is identified by the API key it presents.” Every method in the surface’s Caller Context must be API Key (secret store) or API Key (provider). Otherwise the dashboard shows “Identity ‘From API Key’ needs every Caller Context method to be API Key or API Key Provider” and the surface can’t be saved. What counts as one caller depends on the Caller Context method:
| Caller Context method | One DID per |
|---|---|
| API Key (provider) | Key presented. Each caller with their own key gets their own DID. |
| API Key (secret store) | Secret. Every key value in the secret shares one DID. |
On a direct request, the DID from the presented key replaces any identity the request body asserts. Unless the body asserts the key’s own DID, its trust registry claims are dropped, so a Trust Check preset that reads input.agent.provider_did denies the caller. In policy input, input.agent.did_verification is source_auth for an API Key (provider) caller and unverified for an API Key (secret store) caller.
Protected agent and external agent identity slots.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| API Key | select | Yes | — | Active API key to derive the agent DID from. Populated from the gateway’s configured API keys. |
From version 1.0.5, an inbound From API Key identifies each caller by the key it presents, instead of giving every caller the DID of the key selected in the panel. Callers can get new DIDs, so update any policy rule, Trust Check entry or grant that names the old shared DID.
Type: From JWT Claims
Requires JWT Bearer caller authentication on this surface: every method in the surface’s Caller Context must be JWT Bearer. Otherwise the dashboard shows “From JWT Claims requires a Caller Context whose methods are all JWT Bearer. Remove the other methods, or change this extraction type.” and the surface can’t be saved.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| JWT Claim | string | No | oid | JWT claim from which the DID is derived. |
| Namespace Claims | string, comma-separated | No | — | Additional claims that namespace the derived DID to ensure uniqueness, for example iss, tid. |
Type: Static DID
Static DID is visible in the type dropdown but is disabled and cannot be selected.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| Static DID | string | Yes | — | The pre-known DID to use as the agent identity for all requests. For example: did:web:example.com:agent:my-agent. |
Type: From mTLS certificate
From mTLS certificate is visible in the type dropdown but is disabled and cannot be selected.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| Client Certificate | select | Yes | — | Active client-leaf certificate to derive the agent DID from. Populated from the gateway’s configured certificates. |
Related
- Managed Agent reference: Send signed identity VP to target setting that uses the resolved identity.
- Transit Points reference: Identity on a Managed Agent to Transit Point edge.
Glad to hear it. Thanks for letting us know.
Sorry to hear that. Thanks for letting us know.
Still stuck? Ask the community on Discord or contact us.