Wallet instance attestation on the presentation response
OpenID for Verifiable Presentations (OpenID4VP)
The verifier receives the wallet instance's attestation with the presentation response.
OpenID4VP #799Standards brief
Agent identity across federations and wallets
AI agents now act across organisational boundaries, and the standards that admit them are still being written.
The problem
A major Australian bank needed one trust federation for its own service domains, its partners and the AI agents acting across them.
The bank built it on OpenID Federation. Each participant publishes an Entity Configuration. A Trust Anchor vouches for it through a Trust Chain.
Federation identifies an agent's operator by its Entity Identifier. That Entity Identifier becomes the client_id at the bank's authorisation server.
What federation resolves
- The agent's operator
- Its Entity Identifier, used as the
client_id - Its Entity Configuration and Trust Chain
What it cannot resolve
- The running agent instance
- Installed software with per-instance keys
- No Entity Configuration of its own
The federation knows who operates the agent. It does not know which instance is calling.
The bridge
An Agent Attestation Service closes the gap. It is itself a federation entity, with its own Entity Configuration and Trust Chain.
The service issues each agent instance a Client Attestation JWT, as defined in OAuth 2.0 Attestation-Based Client Authentication (draft-ietf-oauth-attestation-based-client-auth). The sub claim is the federation client_id. The cnf claim carries the instance key.
The authorisation server resolves the attester through the Trust Chain. It authenticates the instance through the Client Attestation PoP JWT, signed with the key in cnf.
-
Agent to Agent Attestation Service
The agent instance requests an attestation. It proves it holds its instance key.
-
Agent Attestation Service to Agent
The service returns a Client Attestation JWT.
subis the operator's federationclient_id.cnfis the instance's public key. -
Agent to Agentic AS
The agent calls the token endpoint with the Client Attestation JWT. It adds a Client Attestation PoP JWT signed with the instance key.
-
Agentic AS to Trust Anchor
The authorisation server resolves the attester's Trust Chain to the Trust Anchor. It then checks the PoP JWT against
cnfand issues a token to that instance.
The agent operator can be an external party or the bank itself. The flow is the same in both cases.
Agents with wallets
The same pattern applies on the credential side.
An agent can hold credentials in a wallet. It can also request them as a verifier. In both roles federation identifies the operator but not the instance.
Three open proposals would carry instance attestation into the wallet ecosystem. None is adopted yet. Each changes an existing standard, so each card has a dashed outline.
Verifier instance attestation
OpenID Federation Wallet Architectures
A verifier instance, such as an agent, presents an attestation of the instance. The wallet checks it against the verifier's federation Trust Chain.
federation-wallet #60x509_hash from MUST use to MUST support
OpenID4VC High Assurance Interoperability Profile (HAIP)
HAIP requires verifiers to use the x509_hash client identifier prefix. The proposal changes this to MUST support. Other prefixes, such as one based on OpenID Federation, stay open to verifiers.
The standards overlay
The overlay maps the agentic banking design onto the standards it depends on.
- Existing standard
- New agentic profile
- Change to an existing standard
What the standards still need
Eight gaps remain open. Each card names the standard, what is missing and the group that owns it.
- New agentic profile
- Change to an existing standard
Client attestation grant profile and attestation API
OAuth 2.0 Attestation-Based Client Authentication
The draft defines the attestation format. It does not define how an instance obtains one, or how attestation applies to agent grants. A grant profile and an attestation API are both needed.
Owner IETF OAuth WG
Agentic Entity profile for purpose and mission
OpenID Federation 1.0
Federation metadata has no place for an agent's purpose and mission. A relying party cannot read what an agent is for.
Owner OpenID Foundation AB/Connect WG
Metadata value search on the Entity Collection Endpoint
OpenID Federation, Entity Collection Endpoint
The endpoint lists entities but cannot search on metadata values. A bank cannot ask the federation for agents with a given purpose.
Owner OpenID Foundation AB/Connect WG
Token Exchange profile for tctx, rctx and purp
OAuth 2.0 Token Exchange (RFC 8693)
OAuth Transaction Tokens define tctx, rctx and purp. No profile says how Token Exchange carries them as an agent's request crosses domains.
Owner IETF OAuth WG
Nested act claims barred from access control
OAuth 2.0 Token Exchange (RFC 8693), section 4.1
Section 4.1 makes prior actors in nested act claims informational only. They cannot inform access control. Agent delegation chains need policy to see the whole chain.
Owner IETF OAuth WG
AuthZEN entitlement discovery on the Grant Management API
Grant Management for OAuth 2.0, with AuthZEN Authorization API 1.0
An agent cannot ask what a grant entitles it to do. AuthZEN search over the Grant Management API would answer that question.
Owner FAPI WG, AuthZEN WG
AuthZEN profile for Protected Resource Metadata
OAuth 2.0 Protected Resource Metadata (RFC 9728)
A protected resource cannot advertise its AuthZEN policy decision point in its metadata. An agent cannot discover how its requests will be authorised.
Owner AuthZEN WG
SSF agentic profile
OpenID Shared Signals Framework (SSF)
SSF defines no events for the agent lifecycle, such as a revoked instance or an ended mission. Receivers cannot act on agent changes as they happen.
Owner Shared Signals WG
About ID Partners
ID Partners designs identity architecture for banks, government and enterprises. It works in the OpenID Foundation and IETF groups that set these standards.