A user signs in once with Google. The platform mints an RS256 JWT scoped to this agent vendor, this scope, for this hour. The agent carries the JWT around as a bearer token; sites verify it locally against a JWKS they cached yesterday.
Five steps, one round-trip per vendor + scope.
- 01Agent rings.Requests permission to act on the user's behalf for a named scope.
GET /id/connect - 02User signs in.One-page consent screen at /id/connect — scopes named, agent vendor named, expiry shown.
Google · OIDC - 03Platform engraves the tag.RS256 JWT signed with a key whose public half is published at /.well-known/aam-jwks.json.
RS256 · 1h - 04Agent presents the JWT.Reuses it across every AAM-aware site for the lifetime of the token.
Bearer - 05Site verifies, alone.Cached JWKS, RSA verify, scope check. The issuer is never on the request path.
verify local
We stay out of the way.
A federation that calls home on every request is a chokepoint with extra steps. Sites pull the JWKS once, cache for a day, verify with their own CPU. That is what makes AAM ID open: anyone can run their own issuer, the contract is just the JWT shape and the JWKS endpoint.
# what the site does on each call 1. read Authorization header 2. decode JWT header, find kid 3. look up public key in cached JWKS 4. verify signature, exp, scope 5. run the action
The sub is a hashed email. Sites recognise repeat visitors without ever knowing the real address. Public keys live at /.well-known/aam-jwks.json on the issuer domain.
Sites can write a small note back to the issuer at /api/aam-id/track when an action goes well. Other sites query /api/aam-id/reputation/<hash> before deciding how generous to be with a first-time visitor. Good actors earn rooms across the whole network.
Cut a key in under a minute.
The consent screen lives at /id/connect. Long-form spec at /spec/identity.