Sessions and proofs
Choose the state and token format belonging to the receiving application.
The current local workspace verifies short-lived possession proofs. A successful verify result is a verified identity; it does not automatically issue an application login session or an ACT.
Current integration choices
For each signed request, use the receiver-issued challenge and durable replay/revocation behavior in local identity. Shared services configure the portable verifier with authoritative adapters and atomic replay consumption.
For an OIDC relying party, use the separately configured OIDC provider. The RP creates its own application session after validating the provider's protocol response. A signed ID token does not automatically grant a tool scope or billing permission.
Older adapter sessions
@openagentid/http@0.1.1 uses opaque strings stored in SessionStore, with Authorization: OpenAgent <session> and a default 300-second lifetime. Its in-memory store is process-local. Read the version-specific identity and concurrency limits before relying on that session.
Older Rust standalone JWTs belong to their original deployment's signing-key and trust configuration. They are not accepted by simply renaming a header in the current APIs.
Keep session material private, use TLS outside the local loopback example, and enforce action/tenant permissions at the receiver. Current SDK verification declarations, older session declarations.