This week

In reply to Kieran Sweeney, Ben Le says -01 will require a receipt with a cumulative limit to name exactly one relying party, which alone counts for the receipt and all its children. A limit without a single named party will be invalid. Sharing a total across relying parties is out of scope, and whether another party in the call path could keep the total is left open. He will define an RFC 9396 authorization_details type for grants so an authorization server that supports RAR can issue root receipts directly, while Token Exchange remains the path for an agent that obtains a receipt using its passport as actor token. He also gives a per-constraint subsumption table (host, port, methods, paths, tools, max_body_bytes, max_calls, max_spend, exp, aud). A child attenuates its parent only if every rule holds, unknown members are rejected, and anything not comparable is rejected. -01 has only a fixed limit of 8 receipts per chain and no depth claim. He plans to join Niki's comparison side meeting on 16 November and hold his own on 17 November, ahead of IETF 127.

• An authorization server that already supports RAR could issue root delegation receipts for agents using a new authorization_details type.
• A relying party enforcing a cumulative spend or call cap on an agent chain must be the one named counter in the receipt.
• Implementers of several agent delegation drafts can use the per-constraint attenuation table as a basis for shared test vectors.

• Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Named in the thread as having its own subsumption rule to compare against.
• Related in IETF WIMSE: draft-hulea-wimse-agent-mandate. Named in the thread (as Hulea) among the drafts whose attenuation rules are to be compared.
• Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. Kieran Sweeney, who replies in the thread, authors this credential delegation draft. This is an inference from the author name only.

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.

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)

• 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.

The PR body argues that Aaron has contributed far more to the document than anyone else, so the attribution should reflect that. It includes a screenshot as an imperfect example measure. No spec text or protocol behaviour changes. The material gives no discussion or outcome.

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.

Mohamad Yossif argues that a chain leaf need not express the binding to one exact request itself. It can carry the digest of, or cite by jti, a separate proof. He describes draft-yossif-psea-03 as a proof signed by the approver's enrolled device over the SHA-256 of the request in RFC 8785 form, which a verifier refuses on replay. He suggests the comparison list "not expressible in the token" and "expressible by reference" as two entries. Iman agrees, would keep the action identifier, approval jti and proof reference distinct, and notes that conformance case DR-C7 only checks a second presentation to the same verifier. Iman proposes a new test presenting one proof through two leaves at two enforcement points and checking that at most one finalization succeeds, which separate local replay caches would not show. The thread contains no draft text change.

• Authors of an agent authorization token who must decide whether per-request approval is carried in the token or referenced from an external proof.
• Deployers running several enforcement points in one verification domain who must decide whether replay state has to be shared across them.

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.

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]

• 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.

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.

The message is a reply to Ben on two open items of the new Agent Passports and Delegation Receipts draft; only Kieran's reply is in the material, not the draft itself. On shared limit accounting between relying parties, he says a cumulative limit needs a single writer that sees every exercise. Separate RPs cannot hold the total, so either the receipt names one RP or a party in the call path keeps the running total. On RAR, he agrees authorization_details can be used for grants, so an AS that already does RAR can issue root receipts. He suggests first lining up the subsumption rule per constraint type, since asor, AAT and Hulea each have their own, and says Niki has offered to compare them before IETF 127.

• An AS that already supports RAR and wants to issue root delegation receipts using authorization_details.
• A designer of a multi-RP agent system who must decide where a shared spending or call limit is counted.

• Related in IETF WIMSE: draft-hulea-wimse-agent-mandate. Named as one of the drafts with its own subsumption rule.
• Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Named as one of the drafts with its own subsumption rule.

Mohamad Khalil Yossif argued that the as_signature in Section 9.4 only proves the AS recorded an approval, not that the approver made it. They proposed draft-yossif-psea (an EAT profile in RATS, signing the SHA-256 of RFC 8785 bytes after user verification) as one way to produce the approver's signature, carried in an optional member of authorization_evidence. They noted it would not close 9.5, since trusted display stays out of scope. The author, Dapeng, replied that the draft deliberately leaves the mechanism open and could add requirements or reference existing IETF work, but that the priority is WG convergence on the problem statement and evidence model. Iman then listed what a signed approver statement should cover: purpose, decision, exact disclosure bytes or canonical digest, approved authority bounds and the approval occurrence. They also asked for a trusted approver-to-credential binding, audience and freshness checks, and an explicit signed-byte boundary to avoid a circular dependency with the AS-signed record. They suggested test cases and said a valid signature with unestablished display provenance should be reported as a separate result. No draft text changed.

sequenceDiagram
 participant A as Approver device
 participant AS as Authorization server
 participant V as Verifier
 AS->>A: Show disclosure and bounds
 A->>A: User verification, sign digest of canonical bytes
 A->>AS: Approver proof
 AS->>V: authorization_evidence with as_signature and optional proof
 V->>V: Compare digest, check binding, audience, freshness

• An AS that records user approvals for agent actions and needs a way to show the approval came from the person, not only from the AS's own record.
• A verifier that must distinguish a valid approver signature from proof of what the person actually saw on screen.

• Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also about signed authorization-evidence records for agent actions, but the mail does not reference it, so the link is by topic.

Mohamad asks to be added to the GitHub repository (account MohamadKhalilYossif) and agrees that requirements should come first. For 9.4 he proposes a short normative list that any approver-side signature must meet, naming no mechanism: it covers the exact disclosure bytes or their digest, it is made by a credential bound to the approver at enrollment, and it identifies the approval it belongs to. Existing work, PSEA included, would then be an informative reference. He will send this as a pull request rather than on the list. This is a proposal in a message, not yet text in the draft.

• An implementer of human-approval flows for agent actions who wants to know what an approver signature must cover.
• A reviewer who wants to follow or contribute to the draft's requirements via pull request.

• Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Similar topic of signed authorization evidence, but the material does not link the two, so this is only a pointer to compare.

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

• 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.

Kieran replies to Caleb and Rob. He accepts Caleb's points 1, 4 and 6 (the remap for a user-issued token, depth-0 values, and 'user-issued'). On how a user-issued root composes with the chain format, he and Rafael still need to agree, and Caleb's jti-as-root shape is a concrete proposal. A mode marker per cumulative key is planned for -03. He cautions that a cumulative budget needs a single writer that sees every exercise, so a tally held at each verifier bounds the total per verifier only, as Section 5.5 already says. -02 names no status mechanism for tokens the DS did not issue, and Section 7 says only that an offline verifier learns of revocation through whatever status mechanism it consults. He values Rob's split between who issued the root and evidence that a person approved it. Section 7 covers revocation only, nothing on suspension or restoration, and the 1-hour cap bounds exposure without closing it.

• A deployer relying on per-verifier tallies who needs to know that a cumulative limit is not enforced across separate verifiers.
• A verifier of delegation tokens issued elsewhere that has to choose a status mechanism because -02 names none.

• Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. This is the draft whose -02 text is being discussed.

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.

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

• 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.

PR #15, which fixes #3 and #10, moves the security and validity claims (cnf, exp, nbf and so on) out of delegate_payload into the base KB-SD-JWT payload. Standard JWT and SD-JWT libraries can then evaluate them without first unpacking the delegate payload. When several delegate_payload entries are present, they share the base KB-SD-JWT's security claims. The PR also adds a section defining how cnf, iat, exp, nbf, aud, nonce, sd_hash and issuer_jwt_hash are interpreted when a KB-SD-JWT is delegated to a new Delegate Holder, versus how subsequent Delegate Holders and Verifiers interpret them, and updates the Verification section to match. Only the PR description was available, not the diff.

• A library implementer who wants existing SD-JWT KB verification to check cnf and expiry on a delegated presentation without delegate-specific unpacking.
• An agent that re-delegates a credential to another holder and needs the audience and nonce semantics to be unambiguous.

Henk Birkholz wrote that the OAuth WG has rechartered to cover authorization and delegation of autonomous agents. He asked whether it plans tangible record or log artifact formats the proposed AUDIT WG could reuse, and said the BoF at IETF 127 aims to reuse as many existing formats as possible. Heime.Jorgen objected repeatedly, arguing that post-hoc records without pre-effect binding invite replay and TOCTOU attacks, and that the charter fails RFC 5434 criteria. They asked for extensibility slots for pre-effect seals and execution nonces. Mirja Kuehlewind replied that the objection was noted and need not be repeated. No OAuth WG member answered Henk's question in this material, and no draft text is involved.

• Authors of agent authorization or delegation drafts who may be asked to make their records usable as audit evidence.

• Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Signed authorization-evidence records for agent actions are the kind of record format the AUDIT BoF asks about.

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

• 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.

Replying to Henk, Mohamad points to draft-yossif-psea, an EAT profile in RATS. In it the approver's enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 canonical form of the action. One independent verifier reproduces the published cases. He says it is meant to be cited, not embedded. He notes that draft-liu-oauth-authorization-evidence records the AS's view of the approval in RAR and recommends approver-side signatures in section 9.4, and that Konrad Gruszka's decision receipts leave that signature open. He proposes the split Mirja described for vCon: the AS record in OAuth, the approver's signature in RATS, and AUDIT profiling how a record references both. This is a discussion post only, and no draft text changed. Only the quoted part of the message is available, so Henk's original question is not visible.

flowchart LR
  A[Approver authenticator] -->|signs SHA-256 of RFC 8785 action| S[PSEA record in RATS]
  AS[Authorization server] -->|RAR approval record| R[OAuth record]
  AUDIT[AUDIT profile] -->|references| S
  AUDIT -->|references| R

• A deployer who needs audit evidence of a human approval for a high-risk action, where the AS logs its own view and a separate user-signed record exists.
• An implementer of RAR-based approval flows who wants to know whether approver-side signatures will be specified in OAuth or referenced from RATS.

Mohamad Khalil Yossif had pointed out that Section 9.4 of draft-liu-oauth-authorization-evidence-02 says the as_signature proves only that the AS recorded an approval, not that the approver made it. He proposed that draft-yossif-psea, an EAT profile in which the approver's authenticator signs the SHA-256 of the RFC 8785 (JCS) bytes of the disclosure object, be carried in an optional authorization_evidence member. He noted this does not close Section 9.5, because trusted display stays out of scope. The author, Dapeng, replied that Section 9.4 only makes a recommendation and deliberately leaves the mechanism open. The draft could later specify requirements or reference existing IETF work. For now the priority is WG convergence on the problem statement and evidence model, and he offered to add Mohamad to the GitHub repository. No draft text changed.

• An AS that records user approvals for agent actions and needs to show later that the person, not only the server, approved them.
• A verifier that wants to compare an approver-signed digest against the disclosure object recorded by the AS.

• Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also defines signed authorization-evidence records for agent actions, so it addresses the same problem space.

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.

Since -25, Section 2.2.2.2 says a credential is of a type if it is the vct value or listed in aka_vcts. The PR removes two leftovers in Section 5.4: a MAY that let a Consumer also match types through the extends property of Type Metadata, and a SHOULD that the vct type extend each type in aka_vcts, which cannot hold for unrelated types since a type can extend only one other. extends now only determines which Type Metadata is inherited. Section 5.4 points to the recommendation in 2.2.2.2 to list extended types in aka_vcts, and Section 7.7 now says aka_vcts types are asserted by the Issuer like the vct type, with the MUST NOT unchanged. The PR says there is no new requirement, that OpenID4VP 1.1 already matches vct_values on vct and aka_vcts, and that ISO/IEC 18013-5 will cite a dated draft at the end of November.

• A verifier matching vct_values must not infer extra types from Type Metadata extends, so results do not depend on which side fetched metadata.
• An Issuer whose credential type extends a parent type that verifiers request should list that parent in aka_vcts.
• An ISO/IEC 18013-5 mdoc profile that delegates type matching to this document.

• Related in OpenID: openid/OpenID4VP. The PR states OpenID4VP 1.1 already matches vct_values on vct and aka_vcts and treats type extension as out of band knowledge.

Only the commit titles are available, and 8 of the 23 are not listed, so this is a partial picture. The titles show CredentialItem.format renamed to credential_format and the format annexes adapted to credential_types being an array. They also show the following. The wallet, not the mdoc, chooses issuer- or device-signed. A substitute data element may be returned where its definition allows. The mapping of support_no_cryptographic_binding to DocRequestInfo was dropped. SD-JWT VC path semantics were deferred to issue #52, and a KB-JWT suggestion was applied. The ISO 18013-5 Document type is no longer redefined as a byte string, the authority key identifier now uses the RFC 5280 name, and RFC 7515 was added as a normative reference. Several other commits are review fixes and housekeeping. Exact wire-format effects cannot be confirmed from titles alone.

• A wallet developer tracking dchp needs to update for the renamed credential_format field and the array-valued credential_types.
• An implementer of mdoc responses needs to know that the wallet selects issuer- or device-signed data.

This message is Paul Williams's reply in the thread about the new draft draft-williams-oauth-poi-core-00. Mohamad Khalil Yossif had suggested that the attestation in PoI Core is close to draft-yossif-psea, an EAT profile in RATS in which the enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 form of the action parameters. Paul agrees the two are complementary. The PoIE attestation block would be extensible by media type, with PSEA as the primary profile for device-bound Tier 2 and Tier 3 assertions, while Tier 1 in-memory Web Crypto session keys stay decoupled from hardware enclaves. He describes the split: PSEA handles the device-bound signature, PoI Core defines the two-phase challenge flow (HTTP 403 with step-up negotiation) and Tier 1 browser keys via IdP certification and PoP chaining, and display integrity is handled by the Resource Server resolving opaque IDs into signed display_facts. He proposes testing an application/psea+jwt token in the PoIE node assertion schema and asks for a sample token from the conformance suite. Nothing is specified yet; this is an early alignment discussion.

sequenceDiagram
 participant C as Client
 participant RS as Resource Server
 participant A as Authenticator
 C->>RS: Request action
 RS-->>C: HTTP 403 step-up challenge
 RS-->>C: Opaque ID resolved to signed display_facts
 C->>A: Parameters plus display_facts
 A-->>C: PSEA token signed after user verification
 C->>RS: Retry with PoIE carrying PSEA token

• A resource server that needs a human to approve a specific high-value action and wants a signed proof tied to the exact parameters shown to the user.
• A deployer weighing browser-only session keys against hardware-backed authenticators for different approval risk levels (Tier 1 versus Tier 2 and 3).

Mohamad comments on draft-liu-oauth-authorization-evidence-02. Section 9.4 says as_signature proves only that the AS recorded an approval, and that deployments needing more SHOULD add approver-side signatures. He cites a case reported on the AUDIT list where a server signed text the person was never shown and still passed the -02 checks. He suggests draft-yossif-psea, an EAT profile in RATS in which the approver's enrolled authenticator signs, after user verification, over the SHA-256 of RFC 8785 bytes. If those bytes are the disclosure object's JCS form, a verifier can compare the digest with the disclosure's. This would not close 9.5, since PSEA leaves trusted display out of scope. He offers proposed text and a worked example against Appendix B.

sequenceDiagram
  participant P as Approver
  participant AS as Authorization server
  participant V as Verifier
  AS->>P: show disclosure object
  P->>AS: PSEA token signed over SHA-256 of JCS bytes
  AS->>V: authorization_evidence with as_signature and optional PSEA token
  V->>V: compare PSEA digest with disclosure digest

• A deployment where a human approval of an agent action must be provable against a compromised or careless authorization server.
• Auditors checking that the text a person approved matches the recorded disclosure.

• Related in IETF WIMSE: draft-munoz-wimse-authorization-evidence. Also defines signed authorization-evidence records for agent actions, though the message does not reference it.

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.

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.

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.

Henk, writing for the AUDIT BoF proponents, notes that the OAuth WG rechartered to include authorization and delegation of autonomous agents, which fits the AUDIT BoF at IETF 127. They ask whether the WG plans tangible record formats that an AUDIT WG could reuse, and say the BoF stance is to reuse as many existing record formats as possible. They invite cross-review and feedback from the WG experts. No answer is included and no text changed.

• Authors of agent authorization drafts who want their records usable for auditing who authorized which action.

Participants discuss aligning AAT, the Asor agent_delegation format and Cred -02 (a Delegation Server design). Niki argues that a holder who sets a smaller del_max_depth than the root (root 8, holder 2) should cap everything below it, so a token at depth 3 is rejected, whereas Asor checks depth only against the root's 8. Kieran notes that a leaf at del_depth equal to the root maximum is accepted by AAT (J.10.f) but rejected under Asor semantics, and wants the test vectors reconciled. Rob agrees the cap should stay and asks the comparison to record whether each draft can bind a leaf to a digest of the exact request. Kieran and Rob both want the companion document for AAT Section 9.8 to state a revocation freshness bound, ideally in terms comparable to Cred -02 Section 7. Niki confirms the comparison and a side meeting. The thread is truncated in the source, so earlier messages are only partly visible.

• Implementers of delegation-chain verifiers who must decide whether a leaf at the root maximum depth is valid.
• Deployers who need a human approval to bind to one exact action inside a broader delegated grant.
• Enforcement points that must state how fresh their revocation state has to be.

• Related in IETF WIMSE: draft-asor-wimse-agent-delegation-chain. Its agent_delegation format and del_max_depth registry entry are the semantics being compared with AAT.
• Related in IETF WIMSE: draft-sweeney-wimse-credential-delegation. Cred -02 is discussed for its Delegation Server ledger and revocation limits, and it adopts the Asor format unchanged for tokens verified away from the DS.

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.

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.

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.

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.

The digest lists GitHub activity only, with no spec text. In draft-ietf-oauth-client-id-metadata-document, 11 issues were closed, including those on token_endpoint_auth_method with private_key_jwt (#100), guidance on omitting token_endpoint_auth_method (#92), unsupported metadata values (#71), AS error returns (#85), disallowing the root path as a URL (#86) and data URIs for logo_uri (#19). One new issue (#131) says the response_types intersection rejects otherwise usable token-endpoint grants. Three PRs were opened, and PR #99 (Add Client Authentication section) got a comment. For oauth-identity-assertion-authz-grant, mcguinness opened #160 (sender-constrained ID-JAG should not replace required client authentication) and #159 (sections 7.2 and 8 require jwt-bearer but omit jwt-dpop). oauth-sd-jwt-vc got 7 new PRs, and PR #450 (Mike Bishop's ballot) got a comment. oauth-v2-1 PR #268 (supporting OAuth 2.0 and 2.1 clients concurrently) got 3 comments. oauth-transaction-tokens got 1 new PR. The digest does not show the reasons for the closures or the content of the PRs.

• An authorization server implementing client ID metadata documents wants to know whether the client authentication and response_types handling rules are still changing.
• An implementer of the ID-JAG grant who plans to use DPoP should watch #159 and #160 on the jwt-dpop gap and on client authentication.

The message is addressed to the author of draft-williams-oauth-poi-core-00 (the thread is titled as the new draft announcement). The sender says the attestation in PoI Core is close to the token defined in draft-yossif-psea, an EAT profile in RATS. In PSEA, the approver's enrolled authenticator signs, after user verification, over the SHA-256 of the RFC 8785 form of the exact action parameters. The sender cites 31 public conformance cases and one independent verifier. PSEA does not cover how the resource server requests approval or how the client key is certified, which PoI Core does define. The sender therefore proposes that the PoIE carry a PSEA token as its attestation and asks whether the author is open to checking the fit. The draft text itself is not in the material, so nothing more about PoI Core is claimed.

• A resource server that wants user-verified approval of one exact action (for example a payment) and must choose between a bespoke attestation format and an existing EAT profile.
• An implementer building a verifier who wants shared conformance cases rather than a draft-specific attestation format.

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.

The contributor noticed that req_wl is a REQUIRED claim but is missing from the JWT Claims Registry Contents in the IANA section, where only tctx and rctx are listed. The PR adds the registration. It is an IANA considerations fix and does not change the token format or processing.