Write it better: good morning we just got door dash delivery that we did not order. We are asking all neighbors if it is theirs. Is this your order? Please see attached picture.
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Rob Zagarella <[email protected]> Sent: Saturday, 08 August 2026 08:53:51 To: [email protected] <[email protected]> Subject: [OAUTH-WG] WGLC review: draft-ietf-oauth-transaction-tokens-11 — support with three comments Hi all, Support for advancing draft-ietf-oauth-transaction-tokens. Review comments from an implementer's perspective - we build agent-orchestration infrastructure where transaction context propagation across service hops is load-bearing for audit evidence, so this document matters to us downstream. Three comments, none blocking: 1. Replacement semantics and audit trails (section on Txn-Token replacement): when a token is replaced mid-transaction, the draft is clear on how the replacement is minted but lighter on what an auditor reconstructing the transaction later can rely on. A short paragraph stating that the replacement chain SHOULD be reconstructible from retained tokens alone (each replacement bearing a verifiable reference to its predecessor) would strengthen the document for compliance-driven deployments - in our sector, the transaction record is frequently reviewed by a party who was not present at execution time and holds only the artifacts. 2. The requester_context claim and downstream trust: the draft appropriately leaves requester_context extensible. It may be worth an explicit security consideration noting that downstream workloads MUST NOT treat requester_context contents as verified claims about the original requester unless those contents are independently signed - we have observed implementers conflate "carried in a signed token" with "attested by the issuer," which are different assurances. 3. Interaction with human-origin transactions: for transactions that originate from a human action, the draft's model carries the subject through sub_id. For deployments where regulation requires demonstrating that a specific natural person stood at the origin of the chain (our case: legal and critical-infrastructure settings under EU AI Act-adjacent obligations), it would help to note that sub_id MAY reference an identity assurance mechanism defined outside this document. No normative change needed — a sentence acknowledging the composition point would prevent divergent profiles. We have documented one such root mechanism in draft-zagarella-verified-human-root-00<https://datatracker.ietf.org/doc/draft-zagarella-verified-human-root/>, offered as a composition example rather than a dependency. Thanks to the authors - the transaction-boundary framing is the right one, and we intend to implement. Roberto Antonio Zagarella Violet Shores — VAC Protocol / Athena https://vacprotocol.org
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
