Best practices for authenticating and authorizing AI agent interactions on top of the WIMSE architecture and the OAuth 2.0 family: which existing standards to apply, where the gaps are.
No explainer written for this spec yet. The summary, relations and documented support below are maintained.
Best practices for authenticating and authorizing AI agent interactions on top of the WIMSE architecture and the OAuth 2.0 family: which existing standards to apply, where the gaps are.
flowchart LR s_aims["AI Identity Management System"] s_wimse_arch["WIMSE Architecture"] s_oauth2["OAuth 2.0"] style s_aims stroke-width:3px s_aims -->|Builds on| s_wimse_arch s_aims -->|Builds on| s_oauth2
Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.
No sourced support entries collected yet. This says nothing about how widely it is used.
Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
Shameer accepts Mikhail's two corrections. The statement that a Serving Party cannot refuse a call because a prior actor is suspended was too broad, because RFC 8693 Section 4.1 only rules out using nested act claims for that decision, not separately verified delegation tokens. The wording becomes: cannot refuse a call on the basis of the nested act claims because a prior actor has since been suspended. The phrase about history being neither complete nor evidence is replaced with: does not by itself establish that it is complete, or that any hop held or narrowed authority. Both edits will go into the next revisions of the SCITT draft and the Evidence Binding draft. No draft text was posted in this message.
draft-ietf-oauth-transaction-tokens. Weak link only: both deal with carrying delegation context across hops, but the material does not reference it.Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
Participants agree to use an at-or-past boundary: state whose age equals S is stale, and a permit is not usable at or after its expiry. Mikhail's example with S = L = 300,000 ms shows that new admissions are bounded strictly before as-of + S + L, assuming zero skew and grace. It does not bound completion of work already admitted. Rerunning the harness with at-or-past expectations against MBA gave 15 of 22 cases agreeing and 7 differing, mostly where MBA compares inclusively at equality. These are described as differences from the convention, not defects. Separately, Marc and Kieran settle that the delegated-subject value must stay identical within a trust domain but may be transcribed when crossing one. Marc proposes the mapping be recorded in the transcribing server's tamper-evident audit record, via suggested changes on PR #176.
New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
Kieran has accepted that RFC 8693 Section 4.1 keeps prior actors in nested act claims out of access-control decisions, and the authors will take that reading in -02. Mikhail notes the SCITT -02 text still says a Serving Party cannot refuse a call because a prior actor was suspended. He points out that separately verified delegation tokens give another basis: a chain in the draft-asor-wimse-agent-delegation-chain-03 format is verified hop by hop, and step 7 denies when an accepted status answer marks any token revoked, within the status list freshness window. He suggests wording limited to refusal on the basis of nested act claims, and rewording the phrase that history is neither complete nor evidence.
flowchart LR A[Token with nested act claims] --> B[Serving party reads top-level claims and current actor only] C[Delegation chain tokens] --> D[Verify each hop] D --> E[Check status list answer] E -->|any token revoked| F[Deny]
draft-ietf-oauth-status-list. The delegation-chain draft's status references and freshness window are checked against a status list answer.The thread continues David Croston's proposal to record in AIMS a gap about trust between trust domains, with a mechanism-neutral property list (verifier trusts another domain's issuer without bilateral setup, issuer speaks only for its names, verifier chooses domains, bounded withdrawal). Jiahui Miao adds a bounding property: accepting another domain's issuer does not by itself establish authorization for an action. ShaoBao Li adds a time half, that a determination holds at the time of observation and not after the evidence expires. Cliff agrees to put one sentence in the gap text and the rest, including recording "not determined" rather than "not permitted", in Section 10.4. Sriram Shankarlingam agrees and notes his DNS-link link token grants nothing. Several messages cite the authors' own drafts and conformance suites.
draft-ietf-oauth-spiffe-client-auth. Related only loosely (workload identity to OAuth client binding); the material does not cite it.New I-D: draft-thaha-wimse-agent-evidence-binding-00 (evidence binding for AIMS audit)
Despite the subject line announcing draft-thaha-wimse-agent-evidence-binding-00, the only message in the file is Kieran replying to Mikhail. Kieran concedes his earlier "policy input" line was wrong because Section 4.1 of the RFC keeps prior actors out of the access-control decision, so deny-listing a prior actor still conflicts with it. Direction (a) is the correct reading and Shameer and Shaibi will take it in -02. Per-hop authority needs separately verified evidence. The announcement text itself is not in the file.
Kieran Sweeney clarified that "sub preserved" means the same principal, not the same bytes. Within one trust domain the value stays identical at every hop (sub fixed, actor in client_id and act). Across a trust domain, transcription under identity chaining is acceptable if the transcribing party records old value, new value and its own identity in what it signs; an AS merely keeping the mapping is not enough for AIMS Section 11. Marc proposes two changes on PR #176 along those lines. Both sides also agree to move the freshness boundary to at-or-past, so the 21 boundary vectors and the 23 October wording change, and the case admitted at exactly S+L becomes refused.
sequenceDiagram participant A as Domain A AS participant B as Domain B AS participant L as Signed audit record A->>B: token with sub value X B->>B: transcribe X to Y B->>L: record old X, new Y, own identity B->>B: issue token with sub Y
draft-ietf-oauth-identity-chaining. The cross-domain transcribed identifier is discussed as OAUTH-ID-CHAIN Section 2.5.Subject: AIMS-00: multi-hop delegation context across agent, tool and resource boundaries
Marc cites Kieran's statements that sub is the Principal at every hop and stays the original delegated subject. He asks whether preserved means the same sub value at every party, including after a hop crosses a trust domain and a party gets a transcribed identifier (OAUTH-ID-CHAIN, Section 2.5). The alternative is that each value refers to the same User and the issuing authorization server keeps the mapping for Section 11. He asks because Nik is proposing text for Section 10.10 on AIMS issues #88 and #90 in which the value may differ between parties, and that text should not conflict with Kieran's property. No answer is in this message.
draft-ietf-oauth-identity-chaining. The message cites OAUTH-ID-CHAIN Section 2.5 for transcribed identifiers across trust domains.draft-zambo-aer1-wimse-mapping-01: AER-1 as a candidate format for AIMS Section 11 audit records
In a thread on draft-zambo-aer1-wimse-mapping, Girish Konda argued that a rejection receipt cannot distinguish a policy denial from a check that could not be completed, since the producer's reason sits outside the committed hash. The -02 added a committed decision_reason member (denied or not_evaluated) with decision_reason_detail. Konda then noted that fail-closed denials after an unreachable or stale input would still be recorded as denied. The author agreed: -03 will use not_evaluated whenever an input the decision depended on could not be established, even if a fail-closed rule denies. The reason is committed for the audit reader and not returned to the caller. -03 will be posted on November 15 after the submission tool reopens.