Security and privacy
Confirm the Service before sending identity material
Network use of the AEP HTTP binding requires TLS 1.3 or later; plaintext HTTP is outside the protocol. An Agent can fetch Inspect without credentials, but it must verify that the origin serving Inspect is bound to the Service DID before provisioning identity material, requesting a signed assertion, or sending credentials. Resolving the DID document proves that the DID exists, not that this origin controls it. A Directory listing or ownership marker cannot replace the origin-binding check.
Without that check, an attacker could advertise another Service's DID from its own origin and induce an Agent to create an assertion naming the victim as its audience. The check is defined by the selected Service DID method; the Discovery and Inspect page explains where it belongs in discovery. A Service should also avoid exposing private operational details through unauthenticated Inspect when they are not needed for interoperability.
Verify the entire client assertion
A Service accepts only identity methods it advertised in identity.methods and signing algorithms it advertised in core.signing_algorithms. It resolves verification material according to the selected identity method's trust, caching, and key-rotation rules. Agents must not use none or symmetric JOSE algorithms for identity assertions.
After verifying the signature, the Service checks aud against its Service DID, op against the requested operation, and resource against the target of an authenticate assertion. It also checks jti for replay and validates iat and exp. Skipping one of these checks weakens the binding even when the signature is valid. The draft allows at most 300 seconds of assertion validity; Services should use short lifetimes and may enforce a shorter ceiling. For protected-resource assertions, the Service consumes jti atomically so two concurrent replays cannot both succeed.
The Agent identity and assertions guide covers creating an assertion. The Identity methods and client assertions page covers the Service verification contract.
Prevent credential disclosure
Grant responses can contain reusable bearer secrets. Agents and Services treat issued session credentials as secrets, follow their expiry and revocation rules, and never log raw values. The Authorization and AEP-Authorization fields are sensitive too; neither belongs in logs, cache keys, idempotency fingerprints, or another protocol document. A stolen session credential may let someone impersonate the Agent until it expires or is revoked. An Agent that suspects compromise can use its baseline client assertion to call Revoke for the affected scope.
An Agent must not forward an AEP assertion or session credential across an origin-changing redirect. For a cross-origin redirect it strips AEP credentials, payment credentials, and authorization headers, restarts anonymously at the new origin, and requires a new valid AEP challenge before authenticating there. It must not copy a Service-selected API-key header to the new origin. A same-origin redirect is allowed only when the credential still authorizes the redirected request; an aep-jwt assertion must be newly signed for the redirect target's resource.
Authentication establishes an Agent principal and any credential metadata; it does not authorize every application action. The protected application still evaluates resource policy and scopes, returning 403 insufficient_scope when authentication succeeds but permission is inadequate. See Protected-resource authentication for the request boundary.
Do not disclose which identity check failed
Unknown Agent identities, bad signatures, wrong audiences or operations, assertion replay, expired assertions, and archived identities all fail as not_recognized. The Service must not reveal which check failed. It should also avoid readily observable timing differences among these paths; rate limits on Inspect and authenticated commands must not create a separate identity-existence signal.
An Agent should handle that error as a failed recognition check, not probe other identities or commands to extract a narrower explanation. The Errors and idempotency page gives the Problem Details codes and retry decisions.
Share only the identity and claims the interaction needs
Inspect lets a Service identify required, preferred, and optional claims before enrollment. Services should keep claims.required limited to data needed for enrollment or legal operation; Agents should avoid sending claims outside those advertised lists. Over-declaring required claims increases privacy risk and reduces interoperability. Services ignore unknown claims unless local policy requires rejection.
Reusing one Agent DID across Services can let those Services correlate activity. Where the identity method allows it and unlinkability matters, an Agent operator or Platform should use a distinct Agent identifier and signing key per Service enrollment. A Service should use an opaque Service-local pairwise identifier for internal records rather than exposing a common cross-Service correlation key.
A Platform-hosted identity can supply Service-scoped DIDs, but the Platform can observe or reconstruct which Services the Agent approaches. An Agent with stronger privacy requirements must account for that trust relationship. Session credentials can likewise become correlation handles when reused outside their issuing Service or exposed to intermediaries, so their presentation rules and raw-value logging restrictions matter beyond authentication.
