On Mon, Apr 20, 2026 at 02:27:46PM +0000, Blake Morrison wrote: > The existing policy correctly separates AI tool attribution > (Assisted-by:) from legal accountability (Signed-off-by:). In practice, > contributors increasingly work across pseudonymous and legal-name > contexts, and a third slot -- identifying the human sovereign identity > under which the work was performed -- lets downstream tooling (CI, > provenance trackers, identity systems) bind a commit to a stable handle > without disturbing the DCO. > > Add Acted-By: as an optional, informational companion trailer. It does > not replace Signed-off-by:, does not change DCO requirements, and does > not mandate any format; the out-of-tree > draft-morrison-identity-attributed-commits defines one such scheme, but > contributors are free to use any handle form they prefer.
This is fairly orthogonal to what LF is already attempting to do with OpenVTC (https://github.com/OpenVTC). I'm giving this a NACK for now, not because I'm trying to stifle this work, but because it's going at it from the wrong angle. The "Acted-by" trailer is clearly intended to be a field for a cryptographic hash, not for a name/email combo. As such, it will most likely never be accepted by the kernel community for the same reason the community rejected the Change-ID trailer -- it's an obscure string of characters that requires specialized tooling to parse. Reading the IETF proposal, this is just one of the trailers proposed, as the following are also mentioned in the draft: 1. Acted-By: 2. Executed-By: 3. Drafted-With: 4. Identity-Signature: 5. Identity-Key-Id: 6. Identity-Anchor: I see that they need to be "optionally provided" but I can guarantee you that a maintainer that sees a patch submission with a slew of trailers like that will reject it (and you will get an earful from Linus). I recommend that instead of starting by introducing a new trailer on the kernel list, you send your overall scheme proposal to the git list instead. Some of the claims in the draft are questionable (e.g. that tree hashes survive rebase or cherry-pick operations), and are specifically suspect within the context of the kernel's patch-based workflow. A tree-hash for a patch created by the submitter will almost certainly become invalid when the maintainer runs "git am" on their series, so the proposed scheme will never really work for the kernel, because the vast majority of cryptographic hashes will never validate. So, NACK for now, and I do recommend you start on the git list instead. -K
