A note on the IETF WIMSE working group's workload-identity work and its agent-identity track, and how AAES's grant envelopes relate to them. AAES implements the same shapes with its own wire format; this is a conceptual mapping, not an interoperability claim.
These pages describe the product. They are not a certification or a legal opinion.
Reading this note
The datatracker is authoritative for the state of any IETF document, and drafts change between revisions — every draft on this page is named with its date. AAES does not emit WIMSE tokens today, so nothing here is a protocol-compatibility statement.
Instrument identity
- Title
- WIMSE (Workload Identity in Multi-Service Environments): the Workload Identity Token (WIT) and Workload Proof Token (WPT) drafts, and the agent-identity track draft-ietf-wimse-aims (AIMS), adopted as a working-group document on 15 September 2026. Revision numbers and dates change between revisions; the working-group document list is authoritative for the current revision of each draft.
- Issuing body
- Internet Engineering Task Force (IETF), WIMSE working group
- Instrument type
- Internet-Drafts on the standards track (working documents, subject to change)
- Adjacent RFCs
- RFC 8693, OAuth 2.0 Token Exchange (delegation semantics) and RFC 9396, Rich Authorization Requests (fine-grained authorization detail)
- Official sources
- WIMSE working group and draft-ietf-wimse-aims on the IETF datatracker.
CIBA-style back-channel binding — binding a human approval to an asynchronous agent request — is the model for the approval shapes below.
Question
How do AAES grants relate to these identity concepts, and what limits interoperability?
For reviewers and procurement teams with an IETF vocabulary: AAES's grant envelopes, per-hop narrowing verification, and provenance-bound decision reasons implement the same shapes as the WIMSE work — bearer-and-proof structure (which bears on freshness and revocation bounds, AARM R6.03), RFC 8693 act-as/on-behalf-of delegation semantics (R6 delegation chains, R2 context accumulation across hops), and RFC 9396-style authorization detail (binding a release to action identifier, target, operation, and parameters, R1.05) — with AAES's own wire format rather than WIMSE tokens.
Selected contribution
| IETF semantic | What a reviewer can examine in AAES | Boundary |
|---|---|---|
| WIT/WPT bearer-and-proof structure | Grants are task-scoped, time-limited, and non-transferable; freshness and revocation bounds are explicit on the grant. | AAES grants are not WIMSE tokens; no wire-format compatibility is claimed today. |
| RFC 8693 act-as / on-behalf-of | Delegation chains with verified per-hop narrowing: a delegated grant can only shrink in scope, and context accumulated across hops is recorded with the decision. | Recorded delegation shape does not establish that the underlying human decisions were correct. |
| RFC 9396 authorization detail | Approvals bind to the exact request — action identifier, target, operation, and parameters — and a changed request needs a new approval. | Binding is to the request as routed through AAES; activity outside AAES is visible only where telemetry is supplied. |
Preconditions and gaps
- AAES does not currently support WIMSE interoperability. AAES plans to evaluate a compatibility layer, so grants can be presented as WIMSE-compatible credentials at the edge, after the AIMS token profile stabilizes. No code change is justified before the draft stabilizes.
- Drafts move. The AIMS draft was adopted on 15 September 2026; cite it by name and date, and re-check the datatracker before relying on any section.
- Credential-path control is required. Activity outside AAES is visible only where telemetry is supplied. Observation is not enforcement.
- No production adoption as of this review. Clients operate their own deployments; AAES does not offer a hosted deployment.
For the exact record and export formats AAES commits to, use the specification. For implementation and testing details, use Security and implementation posture and the evaluation page.
Client responsibility
The organization operates its own workload-identity infrastructure and evaluates the WIMSE and AIMS drafts against it. AAES's grant flows mirror RFC 8693 and RFC 9396 semantics; that resemblance does not make any deployment conformant with those drafts. The client remains the regulated entity.
Identify the credential path, actions, and evidence questions to examine in a client test tenant.