The WIMSE list this run had no new draft text: discussion of agent delegation and revocation in draft-ietf-wimse-aims and related drafts, plus IETF 127 hackathon interop scenarios for agent call chains. The main takeaway is that revocation and fail-closed behaviour are becoming the shared test target.
Updated 13 November at 06:50 UTC
Where the specs stand
IETF drafts by Datatracker state. Highlighted ones changed in the last seven days.
The evidence-binding authors will narrow a claim about suspended prior actors so it no longer conflicts with RFC 8693 Section 4.1.
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.
A Serving Party deciding whether it may deny a call based on a suspended prior actor, using verified delegation tokens rather than nested act claims.
Related in OAuth WG: draft-ietf-oauth-transaction-tokens. Weak link only: both deal with carrying delegation context across hops, but the material does not reference it.
Discussion
The AIMS/MBA thread settles on an at-or-past (exclusive) expiry rule and on allowing a transcribed delegated-subject value across trust domains.
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.
An implementer of permit or token expiry checks deciding whether equality at the boundary counts as expired.
A cross-domain agent gateway that must rewrite the delegated subject identifier while keeping it auditable.
Discussion
An IETF 127 hackathon plan for WIMSE agent call chains drew proposed negative test scenarios centred on revocation and fail-closed checks.
Alexander Pelov will run interop scenarios across independent implementations (SPIRE with experimental WIT-SVID, go-spiffe, Cofide's PoC and a Python implementation). The scenarios use workload-creds-03, wpt-02, http-signature-08, identifier-04, Txn-Tokens and identity chaining across two trust domains, with a shared transaction ID in logs. The normal path binds a Txn-Token to each hop's proof, and the Txn-Token never leaves its domain. Replies from Ben Le (draft-le-agent-passport) and Iman add cases: unreachable status list, revocation after delegation, widening delegation, cumulative limits across two services, request rewritten by a proxy and tool-description digest changes. Iman asks that logs distinguish confirmed revocation, expired status cache and unavailable status service, and that a revoked authorization blocks the operation before effect.
sequenceDiagram
participant A as Agent A (domain A)
participant B as Agent B
participant R as Receiving hop
A->>B: delegate
B->>R: first call
R-->>B: accepted
Note over A: A is revoked
B->>R: next call
R-->>B: rejected (fail closed)
Who this affects
An implementer of WIT/WPT or Txn-Tokens wanting shared negative test cases to compare against other implementations.
A deployer defining fail-closed policy when a status list is unreachable or a delegating agent is revoked mid-chain.
Related in OAuth WG: draft-ietf-oauth-transaction-tokens. The scenario binds a Txn-Token to each hop's proof and keeps it inside its domain.
Related in OAuth WG: draft-ietf-oauth-identity-chaining. Crossing to trust domain B uses identity chaining.
Discussion
Credential-delegation -03 will cover cumulative-budget tally limits and a status location for user-issued grants.
Caleb accepts Kieran's review points 1, 4 and 6 and the jti-as-root shape for composing a user-issued root with the chain format. For -03 he agrees a tally held at each verifier bounds the total per verifier, not across verifiers, so a cumulative budget needs a single writer that sees every exercise. He also accepts the status gap: since a user cannot run a status endpoint, the grant must name where its status lives, and he will bring text. Quoted earlier, Rob suggests keeping who minted the root separate from evidence that a person approved it, and asks Section 7 to say what verifiers see for actions during a suspension and whether a restored delegation is the same grant; Kieran notes -02 Section 7 covers revocation only.
Building a delegated-credential service that enforces a cumulative spending or call budget across several verifiers.
Issuing a delegation root directly from a user, where there is no server to host a status endpoint.
Discussion
Thread on multi-hop delegation settles on an exclusive at-or-past rule for state age and permit expiry.
Mikhail agrees to change his 23 October example to exclusive limits: state whose age equals S is stale, and a permit is unusable at or after its expiry; issuance needs a permit deadline later than issuance time. With S enforced at final issuance and permit lifetime bounded by L, new admissions are bounded strictly before original as-of + S + L (assuming zero skew and grace), though completion of already-admitted work is not bounded. Re-running the harness against MBA at commit ea1a149 gives 15 of 22 cases agreeing and 7 differing, where MBA compares inclusively at equality; he calls these differences from the convention, not defects. In the quoted message Marc asks Kieran to confirm that a transcribed delegated-subject value across a trust domain is acceptable if the transcription (old value, new value, server identity) is in the server's tamper-evident audit record, and proposes two changes on PR #176.
Implementing permit or mission-bound authorization expiry checks, where the boundary instant (equal to expiry) must be treated as expired.
Writing test vectors for staleness and expiry so that independent implementations agree at equality.
Deciding how a server records a subject identifier it rewrites when a request crosses a trust domain.
Discussion
Mikhail asks the evidence-binding authors to reword claims that a serving party cannot refuse a call over a suspended prior actor.
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]
Who this affects
Designing an audit or serving-party policy for multi-hop agent calls where an upstream actor is later suspended.
Choosing whether per-hop authority is checked from act claims (attribution only) or from separately verified delegation tokens with status references.
Related in OAuth WG: draft-ietf-oauth-status-list. The delegation-chain draft's status references and freshness window are checked against a status list answer.
Discussion
AIMS cross-domain gap text: agreed to add bounding sentences that issuer trust does not decide authorization and that determinations expire.
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.
Federating agents across organizations where no bilateral trust bundle exchange exists.
Auditors needing to tell apart refused because authority could not be determined and refused because the operation is not permitted.
Related in OAuth WG: draft-ietf-oauth-spiffe-client-auth. Related only loosely (workload identity to OAuth client binding); the material does not cite it.
Discussion
One short reply: act is attribution, not a policy input, and the evidence-binding authors will take that in -02.
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.
AIMS delegation thread: the delegated subject may differ across trust domains if the transcription is in the signed record.
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
Who this affects
A deployment where an agent chain crosses trust domains via identity chaining and needs auditors to reconstruct the original user from records alone.
A verifier implementing the S+L revocation-admission bound that must decide whether an input exactly at its limit is accepted.
Related in OAuth WG: draft-ietf-oauth-identity-chaining. The cross-domain transcribed identifier is discussed as OAUTH-ID-CHAIN Section 2.5.
Discussion
AAT, Asor and Cred -02 authors agree a child's lower del_max_depth must be honoured, and compare constraints before IETF 127.
Kieran agrees that the effective maximum depth at any hop is the lowest del_max_depth on the path, and that this cap is separate from the question of the leaf at the maximum (AAT J.10.f accepts a leaf at del_depth equal to the root maximum, Asor -03 rejects it). Rob Zagarella asks the comparison of the three drafts to record whether each can bind a leaf to a digest of one exact request; Kieran says Cred -02 cannot express that in the token today, and its Section 5.5 takes the chain format by reference so its entry for off-DS verification is provisional. Rob also asks that the AAT Section 9.8 revocation freshness bound be stated in the same terms as Cred -02 Section 7. Niki holds a side meeting on 16 November in San Francisco.
Implementers of attenuating delegation tokens who need to know whether a leaf at the maximum depth is accepted.
Human-approval flows where an approval must bind to one exact action such as a payee and amount.
Related in OAuth WG: draft-ietf-oauth-transaction-tokens. Not referenced in the material; omit if unsure.
Discussion
Review of Cred delegation -02: user-issued roots, tally mode and revocation status are the open points for -03.
Kieran's -02 announcement describes a Delegation Server (DS) that holds deposited user credentials and lets agents exercise them by proxy under a delegation token. It adds sub-delegation exchange (5.4.1), rank order in the token, delegation_constraints with max_lifetime and max_subtree written only by the DS, a chain-verifiable profile (5.5) adopting the Asor agent_delegation format unchanged, revocation text stating revoked_count is invalidation not closure, and ML-DSA. Caleb Dayton raises six points, including the claim remap for user-issued tokens, using the token's jti as root receipt, a mode marker for single-writer versus delegate-held tally, and a status mechanism when no DS exists. Kieran agrees to a per-key mode marker but cautions that a per-verifier tally does not bound the total across verifiers, and says -02 names no status mechanism for tokens the DS did not issue. Rob Zagarella suggests separating who issued a root from evidence a person approved it, and asks Section 7 to cover suspension and restoration.
sequenceDiagram
participant U as User
participant DS as Delegation Server
participant AG as Agent
participant UP as Upstream resource
U->>DS: deposit credential
DS->>AG: delegation token
AG->>DS: exercise under token
DS->>UP: call with deposited credential
DS->>AG: result and receipt
Who this affects
An agent platform where users deposit OAuth credentials with a proxy and agents never hold the upstream token.
A verifier away from the DS that must decide whether a cumulative budget has been exceeded.
Related in OAuth WG: draft-ietf-oauth-identity-chaining. Not named in the material; omit.
Discussion
A reviewer says the agent-mandate draft should only let an RP un-count an unused token on positive evidence, not on missing confirmation.
Dmitri Chistyakov comments on Section 9.5 of draft-hulea-wimse-agent-mandate-01. The draft treats unresolvable status as indeterminate and denies by default, but says that if a token expires unused the RP MAY remove its contribution to a cumulative limit. The contribution is recorded when the token is issued (Section 10.2), yet the draft does not say how the RP learns the token was unused. If the RP infers this from a missing or late execution confirmation, it can remove the contribution of an action that did run. The budget is then under-counted and a later request can pass the sum_max check wrongly. The proposed text allows removal only on positive evidence trusted under RP policy or the Trust Framework, such as a statement from the resource server that it never accepted the token. Absence of a confirmation does not count. Without such evidence the contribution stays recorded, which may cause an unneeded denial until it leaves the period window. The sender notes the message was prepared with AI assistance. This is a review comment, not a change to the draft.
sequenceDiagram
participant RP
participant RS as Resource server
RP->>RP: record contribution when token is issued
Note over RP: token expires, no confirmation seen
RP->>RS: ask whether the token was ever accepted
RS-->>RP: never accepted, stated after expiry
RP->>RP: remove contribution
Note over RP: without this statement the contribution stays
Who this affects
An RP enforcing a per-period spending or action limit on an AI agent using mandate tokens, where execution confirmations can arrive late or be lost.
A Trust Framework author defining which party may attest that a token was never accepted.
Discussion
A reviewer asks that section 5.4 state that its entries describe the evaluation instant only, not the moment of the effect
Cliff supports adding an optional decision.evaluatedAt field, alongside Marc's malformed case. He notes this does not settle the gap between freshness at evaluation and freshness at the effect. Because the record already carries effect.interval.openedAt, a reader can compute an input's age when the effect began. He asks for one sentence in 5.4 saying the entries speak to the evaluation instant only. He also asks for a test record whose standing is fresh at evaluatedAt but past maxAge at openedAt, to be accepted as well formed. The message does not name the draft, and the thread's earlier context is not included, so the surrounding proposal is only partly visible.
An implementer validating decision records needs to know whether a stale input at effect time makes the record malformed or only informational.
An auditor reconstructing an action from a record wants to compute input age at effect start from effect.interval.openedAt, without treating evaluatedAt as proof of freshness at that time.
Discussion
Audit-record test corpus: an input exactly maxAge old becomes stale, and an optional decision.evaluatedAt is proposed.
Sankalp Gilda agrees the freshness boundary is at-or-past: in the next revision of draft-gilda-audit-agent-audit-record an input is fresh only while its age is less than maxAge, so test record FR2 (exactly maxAge old) becomes a reject case. Because the record carries only decision.reportedAt, he proposes an optional decision.evaluatedAt, with age measured there when present and at reportedAt otherwise, plus test records on each side of the boundary. Marc supports this, noting that standing taken from a published commitment depends on its age when the decision was taken, and adds that an evaluatedAt later than reportedAt beyond the skew tolerance should be refused as malformed. A withdrawn-principal wording from Girish goes into Section 5.
Authors of audit-record verifiers who need a defined result for evidence exactly at its maximum age.
Decision points that report late and would otherwise appear stale when age is measured at the report time.
Discussion
AAT, Asor and Cred-02 authors try to agree one meaning for del_max_depth and compare constraints before IETF 127.
In this thread Niki (AAT) and Kieran (Cred-02) agree that each registry name should have a single entry, so the open point is how del_max_depth is interpreted. With a root del_max_depth of 8, AAT accepts a leaf at del_depth 8 (test vector J.10.f) while the Asor format rejects it. Niki adds that if a holder re-delegates with del_max_depth 2, AAT rejects a token at depth 3, whereas Asor checks only against the root's 8. Niki wants the shared definition to keep that cap. Rob supports keeping it. Kieran leans toward the Asor entry but cares more that the vectors are reconciled. Niki will add a test case for the capped scenario. Kieran separates chain-wide budgets, which need a single writer such as the Cred-02 Delegation Server ledger, from offline attenuation. On revocation, he asks the AAT Section 9.8 companion document to state a freshness bound for the enforcement point, in terms comparable to Cred-02 Section 7. Rob asks the comparison to record whether each draft can express a leaf bound to a digest of the exact request. Niki will have the comparison ready before IETF 127 and confirms a side meeting in San Francisco.
An implementer of agent delegation who must decide whether a leaf at the root's maximum depth is accepted or rejected.
A deployer who needs revocation of delegated tokens to take effect within a bounded time at enforcement points.
A human-approval workflow that must bind a delegated token to one exact action, such as one payee and amount.
Discussion
Kathleen's review of draft-ietf-wimse-wpt asks why jti replay checking is only RECOMMENDED and what collision-resistant claim names means.
The review is mostly editorial and reads the draft as a clear guide for implementers. It asks to break out the Key Characteristics paragraphs. From a security view it asks why the check that a jti has not been used before in the WPT validity window is RECOMMENDED rather than MUST. It also asks what collision resistant means for a claim such as example.com/myclaim, since the term usually refers to hash functions. No text change has been made.
An implementer deciding whether to enforce jti replay detection on WPTs when the draft only recommends it.
Discussion
Marc asks whether sub being preserved at every hop means the same value everywhere, even across trust domains.
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.
A multi-domain agent deployment where a downstream authorization server issues a different identifier for the same user.
Related in OAuth WG: draft-ietf-oauth-identity-chaining. The message cites OAUTH-ID-CHAIN Section 2.5 for transcribed identifiers across trust domains.
Discussion
Kathleen's review of the mTLS draft asks it to cover key-pair authentication, not just path validation and naming, and thinks WGLC is possible.
The review proposes adding at the transport layer to the first sentence of the Introduction. It suggests a new section before 3.2 on authenticating the workload with the key pair tied to the certificate, including provisioning when the workload must match expected key pairs. In Section 5.1 it proposes wording so the server is authenticated using its credentials and key pair, not only the workload identity name. It also proposes that a server doing mTLS MUST validate the client certificate chain and key pair, as well as trust domain and Workload Identifier. With these changes the reviewer sees WGLC as possible.
An mTLS implementer who wants the spec to say explicitly that proof of possession of the certificate key is part of authentication, alongside chain and identifier checks.
Discussion
An individual draft will treat an input exactly maxAge old as stale, and the author floats an optional decision.evaluatedAt.
Sankalp Gilda replies to Wes, Blake, Kieran and Girish. He agrees the freshness boundary is "at or past", so an input is fresh only while its age is less than maxAge. The next revision of draft-gilda-audit-agent-audit-record (after -03) will say this, and his test record FR2, an input exactly maxAge old, becomes a reject case. He asks whether an optional decision.evaluatedAt would fit. Age would be measured there when present and at decision.reportedAt otherwise, and he would add test records on each side of the boundary for a decision point that reports late. He will put Girish's wording "an issuer or a principal whose standing is withdrawn" into Section 5, with a withdrawn-principal record. He also asks Wes for the -06 text of Section 3 and 3.2 so he can mirror it. The message does not say which draft the -05/-06 text belongs to, and no WG draft text changes in it.
An implementer of an audit or evidence verifier who must decide whether an input exactly at the maxAge limit is accepted.
A decision point that reports its result late and needs the age check done at the evaluation instant instead of the report time.
Editorial
Kathleen's review of identifier-04 has one nit: say that credentials means WIMSE workload credentials.
The only comment concerns the last paragraph of Section 5. It proposes changing the final words from credentials to WIMSE workload credentials, so readers know it refers to the credential formats of [WIMSE-CREDENTIALS]. The review otherwise finds the document well written. This is a terminology fix with no protocol change.
Weekly WIMSE GitHub digest: new issues on HTTP-Sig test vectors, nonce examples and shared trust anchors, plus a spelling-fix PR
The digest lists five new issues on draft-ietf-wimse-s2s-protocol. Two concern draft-ietf-wimse-http-signature-08: a request for test vectors (#419, four comments) and a note that sample nonces in the examples are illustrative and below the entropy floor (#420). Two are editorial-comment trackers for the HTTP-Sig and workload-creds drafts (#417, #418). Issue #416 proposes requiring name-constrained issuing CAs when a trust anchor is shared across trust domains. It also drew a comment on #370 (overlapping trust roots, labelled workload-creds and mutual-tls) and on arch PR #142 (Terminology). Issue #414 (Reconcile Coexistence) got one comment, and PR #415 fixes three spelling errors. The digest gives only titles and comment counts, so no proposed wording or decisions are visible, and no draft text changed.
An implementer of WIMSE HTTP message signatures waiting on test vectors to validate interoperability can follow issue #419.
A deployer where several trust domains share a root CA can follow issue #416 and #370 on whether name-constrained issuing CAs will be required.
Substantive change
The AER-1 mapping for AIMS audit records will separate denied decisions from decisions that could not be evaluated.
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.
A deployment producing tamper-evident audit logs for AIMS Section 11 needs to tell policy denials from unreachable or stale policy and status sources.
A fail-closed policy point can keep returning a uniform error to callers while still recording why it denied.
Discussion
The AAT and Asor drafts disagree on del_max_depth, and the thread favours a shared definition that lets a holder cap depth below its own position.
This thread compares delegation-constraint drafts ahead of IETF 127. AAT accepts a leaf at del_depth equal to the root's del_max_depth (test vector J.10.f) while asor -03 rejects it. A second difference from Azat's implementation report: if a root has del_max_depth 8 and its holder delegates with 2, AAT rejects depth 3 while Asor checks only against 8. Niki argued the shared definition should keep the cap, and Rob Zagarella's new reply agrees. Zagarella also asked that the comparison record whether each draft can bind a leaf to a digest of the exact request, and that the AAT Section 9.8 companion document state a revocation freshness bound in terms comparable to Cred -02 Section 7. The material shown is truncated.
Implementers of offline-verifiable delegation chains need identical depth-limit behaviour across drafts to avoid interoperability failures.
Deployments requiring fresh human approval want a leaf bound to one exact request.
Discussion
Rob Zagarella commented on Cred delegation -02: keep human-approval evidence separate in a user-minted root, and specify suspend/restore semantics.
The thread carries Kieran Sweeney's -02 announcement. The draft is a profile where a Delegation Server holds user-deposited credentials and agents exercise them by proxy under a delegation token. Main changes are a sub-delegation exchange, rank order in the token, cumulative bounds (max_lifetime, max_subtree) with the DS as single writer, a chain-verifiable profile adopting draft-asor-wimse-agent-delegation-chain's agent_delegation format, and revocation framed as invalidation, not closure. Zagarella's reply, the new message, suggests that -03 distinguish who minted a root from evidence of natural-person approval, recording only method and assurance. It also asks Section 7 to say what a verifier sees for actions during a suspension and whether a restored delegation is the same grant, with the 1-hour cap presented as a bound on exposure.
An agent platform that lets users deposit upstream credentials and delegate to agents without exposing them.
A verifier away from the Delegation Server needs a fixed place to check human-approval evidence for a user-minted root.
Related in OAuth WG: draft-ietf-oauth-transaction-tokens. Both carry delegated authority across call chains, but the material does not link them explicitly; weak connection.
Discussion
Independent test vectors for http-signature-08 were posted; the chair says verifiers should reject sender-side MUST NOT parameters.
Jiahui Miao posted 6 positive and 22 negative vectors for draft-ietf-wimse-http-signature-08 (issue #419 in the s2s-protocol repository), each negative case tied to a MUST in the draft, with keys, signature bases and a fixed clock. Two questions: whether a verifier should reject or ignore keyid/alg parameters, and whether the Section 3.7 example nonces, which carry less than the 64-bit minimum, deserve an editorial note. Yaron replies that a MUST NOT in a security RFC should be rejected by the recipient, an issue to add that note has been opened, and a few vectors may need fixing (details in the issue). The nonce question is not answered in this reply.
Implementers of WIMSE HTTP message signatures who want interop test cases for rejecting malformed requests.
Verifiers deciding whether to reject or silently ignore forbidden signature parameters.
Discussion
A reviewer suggests mostly readability edits to workload-creds, plus questions on exp lifetime, deny-list wording and mTLS in Section 9.6.
The reviewer proposes rewording the abstract so credentials are 'bound to' the workload identity rather than 'represent' it. They also propose restating the WIT (application layer, e.g. HTTP) versus WIC (transport layer, mTLS) split as two recommended patterns, with a rationale. For Section 5 they suggest explaining why TLS termination at a load balancer calls for an application-layer credential that stays unaltered. On Section 5.1 they ask whether the 'hours' guidance for exp should be shorter, since some deployments already use about 5 minutes, and why jti text says deny-list rather than allow-list. They suggest Section 9.2 mention that short exp values mitigate the problem it describes. The one normative edit is in Section 9.6, where the requirement to send the WIT and PoP over a 'server-authenticated TLS' connection would also name mTLS. No WG response is in the material.
An implementer choosing WIT lifetimes would watch whether the WG tightens the 'on the order of hours' guidance for exp.
A deployer sending WITs over mTLS between services would benefit if Section 9.6 states that mTLS satisfies the channel requirement.
Discussion
A thread on AIMS -01 converges on two bounding sentences for the gap text, with the rule placed in Section 10.4.
Lee (author of draft-li-rttp-iqa-addressing) and Jiahui Miao agree to put one bounding sentence in the AIMS gap text and the undeterminable-state behaviour in Section 10.4, where the accepting domain's own evaluation is described. The first sentence says that accepting another domain's issuer does not establish authorization for an action. The second says a determination made from observed evidence holds at the time of observation and does not by itself hold after that evidence expires. Lee supports this with his own draft's closed five-value refusal vocabulary and an observation_as_of_ms field. This is a proposal from one participant, not a WG decision. The message is truncated, and the other drafts and conformance sites it cites are self-promotion that I did not verify.
Deciding how a verifier treats a certificate from another trust domain's issuer when AIMS leaves authorization undetermined.
Designing a cross-domain acceptance audit record that includes the age of the evidence relied on.
Discussion
Kathleen Moriarty's review of workload-creds suggests clearer wording and a few security tweaks; Yaron logged it as issue #418.
The review proposes rewording the abstract to say credentials are bound to the identity rather than represent it. It also proposes stating directly in the introduction that the WIT is for application-layer protocols such as HTTP and the WIC is for transport-layer protocols, mainly mTLS. For Section 5 it suggests explaining that TLS termination at a load balancer is a reason to use an application-layer credential. For Section 5.1 it asks whether the exp guidance of hours should be shorter, and why the draft says deny-list rather than allow-list. For Section 9.6 it suggests allowing mTLS as well as server-authenticated TLS. The message is truncated, so later comments are not visible. Yaron recorded it as s2s-protocol issue #418. These are suggestions, not adopted changes.
Implementers choosing between WIT and WIC for a deployment with TLS-terminating load balancers.
Operators setting WIT lifetimes and deciding between deny-list and allow-list status mechanisms.
Related in OAuth WG: draft-ietf-oauth-status-list. The review questions deny-list versus allow-list token status in the WIT, which is the area Token Status List covers; the material does not link the two drafts.
Editorial
A reviewer suggests wording changes to the http-signature introduction to state the full scope and why application-layer protection is used.
The reviewer notes the draft is past WGLC and judges the rest of the document very good. They propose adding 'HTTP' to the first sentence of the introduction so the full scope is stated at once. They also propose rewriting the introduction's rationale for application-layer protection. The new text says the motivation is consistent identifier and credential handling across the full transit path, including TLS sessions terminated and restarted at proxies or middleboxes, using HTTP signatures with a JWT. No protocol change is proposed, and no WG response is in the material.
Kathleen Moriarty's review of http-signature asks for a one-sentence HTTP scope and a clearer reason for application-layer protection; logged as issue #417.
The review says the draft is clear and in good shape. It suggests adding HTTP to the first sentence of the introduction. It also suggests rewording the paragraph on why deployments prefer application-layer protection. The proposed text says TLS may involve several hops that terminate and restart sessions, such as at a proxy or middlebox, and HTTP signatures with a JWT keep one identifier and credential across the path. It is a wording change only and does not alter the protocol. Yaron noted it as s2s-protocol issue #417.
This is a short reply from Sean to Yuan, quoting an earlier thread. Yuan had asked for five minutes at the joint WIMSE/OAuth session to present draft-liu-oauth-cross-domain-txn-token, which targets the same use case as the Cross-Domain Transaction Tokens item already on the agenda. Sean says that after talking with Pieter and George, Yuan is welcome to ask questions but co-presenting is not an option for now. The quoted call for agenda items says the OAuth chairs requested two two-hour slots plus a joint WIMSE/OAuth session. It also says items with demonstrated interest from several parties get priority, and gives 2 November 2026 as the draft submission cut-off. No protocol text changed.
Related in OAuth WG: draft-ietf-oauth-transaction-tokens. The joint session item concerns transaction tokens extended across domains, and the competing draft targets the same use case.
Minor or unclear
A side meeting on Attenuating Authorization Tokens is set for IETF 127, Monday 16 Nov, 11:15 PST.
Niki announces a side meeting in Continental 7 and on Webex. Topics are implementation experience, integrations with HTTP APIs, MCP, A2A and agent frameworks, what belongs in the core document versus profiles, and alignment with related delegation chain drafts in OAuth and WIMSE, including common test vectors.
Minor or unclear
Test vectors for the WIMSE HTTP signature draft were fixed: @query values lacked the leading ? required by RFC 9421.
An individual contributor reports on the mailing list that test vectors P-01 and P-02 wrote the @query component value without the leading ? required by RFC 9421 Section 2.2.7. An independent run found the same defect in P-06's WIMSE signature. All three were regenerated over corrected signature bases with the same keys, parameters and fixed clock. The literal signature in N-15 was also regenerated because it was computed over a P-01-shaped base. Its expected outcome (reject, Section 3.1) is unchanged. Old signatures fail against the corrected bases, and other cases are unaffected. The author also confirms that N-06/N-07 record reject for the keyid / alg MUST NOT parameters, now backed by the draft author's stated intent. An issue was opened to add an example-nonce note. The author will contact the chairs about how to contribute the vectors. Nothing in the draft itself changed.
Minor or unclear
One commit fixing three spelling errors in the s2s-protocol repository.
Commit 499f0608fc22 (#415) fixes three spelling errors in the wpt directory or component, going by the message 'wpt: fix three spelling errors'. No further detail is available and no protocol behaviour is indicated.
Full daily report for 2026-11-13
WIMSE Daily Report (2026-11-13)
Generated at: 2026-11-13T06:49:48+00:00
Snapshot
Active WG drafts: 8
Related drafts: 20
Mailing-list posts scanned: 40
Tracked GitHub repos: 6
Active WG Drafts
Draft
Date
Title
draft-ietf-wimse-aims-01
2026-11-02
AI Identity Management System
draft-ietf-wimse-workload-creds-03
2026-10-30
WIMSE Workload Credentials
draft-ietf-wimse-workload-identity-practices-08
2026-10-30
Workload Identity Practices
draft-ietf-wimse-mutual-tls-03
2026-10-24
Workload Authentication Using Mutual TLS
draft-ietf-wimse-identifier-04
2026-10-23
Workload Identifier
draft-ietf-wimse-http-signature-08
2026-10-20
WIMSE Workload-to-Workload Authentication with HTTP Signatures
draft-ietf-wimse-wpt-02
2026-08-27
WIMSE Workload Proof Token
draft-ietf-wimse-arch-08
2026-07-06
Workload Identity in a Multi System Environment (WIMSE) Architecture
Recent Related Drafts
Draft
Date
Title
draft-hulea-wimse-agent-mandate-01
2026-11-01
Verifiable Mandates for Agents Acting Across Administrative Domains
draft-thaha-wimse-agent-evidence-binding-03
2026-11-01
Evidence Binding for AI Agent Credentials
draft-reddy-wimse-oauth-dialog-binding-00
2026-10-30
Binding Agent Dialogs to WIMSE and OAuth Credentials
draft-sweeney-wimse-credential-delegation-02
2026-10-30
Credential Delegation Protocol for AI Agents in Multi-System Environments
draft-durga-wimse-ctx-isolation-00
2026-10-29
Cryptographic Separation of Untrusted Data-Plane Context from Control-Plane Tool Invocations in Autonomous AI Agents
draft-jackson-wimse-evaluation-05
2026-10-28
Verifier-Side Evaluation Semantics for Delegated Authority Chains
draft-asor-wimse-agent-delegation-chain-03
2026-10-27
Verifiable Attenuated Delegation for AI Agent Chains
draft-ni-wimse-ai-agent-identity-04
2026-10-27
WIMSE Applicability for AI Agents
draft-uppalapati-wimse-pq-agent-identity-01
2026-10-27
Post-Quantum Requirements for Software and AI Agent Identity