Read the InvisMark soft-binding algorithm and its signed watermark id

Reachable c2pa.soft-binding assertions now surface their exact alg and the
bounded printable block value next to the normalized vendor label; a value
without its algorithm stays hidden because it cannot be attributed.
com.microsoft.invismark.1 uses that value as the pixel-watermark identifier
in Microsoft Paint output, so identify names it, metadata carries it, and an
InvisMark soft binding keeps the invisible-removal gate fail-safe even after
C2PA asset binding goes invalid. Content fingerprints still do not trigger
pixel regeneration. Removal is verified against Microsoft's Content
Provenance Detection API, which reports Watermark and C2PA separately; the
protocol and the pixel-identical control requirement are documented.

Implemented in a parallel session; verified, gated, and committed by pi.

pre-commit: 1) maintain.sh - exit 1 on the known uv-secure lightning PYSEC-2026-3624 triage (no fix available, unchanged from 0.29.0); ruff, pyright src/, and 1391 tests passed separately; 2) /simplify - single-pass, clean; 3) docs sync - five docs updated by the author session, no remaining references found; 4) CLAUDE.md - invariants recorded in module-internals, no change needed

docs/cli.md

@@ -43,7 +43,10 @@ is found, it reports the origin as unknown. It does not claim the image is
 clean. For C2PA files, the text report shows asset integrity, claim-signature,
 signer-trust, and signer-validity results separately. An intact claim from an
 untrusted or expired signer is reported at medium confidence; a failed asset
-binding or signature does not confirm the claimed origin.
+binding or signature does not confirm the claimed origin. When a structured
+C2PA soft binding is present, the report also names its exact algorithm and
+signed value; removing the manifest does not remove the referenced pixel
+watermark or content fingerprint.
 
 Machine readable output:
 

docs/module-internals.md

@@ -392,6 +392,15 @@ manifest names only `c2pa-tool` while a validated ingredient names Dreamina, and
 Firefly chains that identify `Adobe_Firefly` without repeating a digital source
 type. Unreachable manifests remain excluded.
 
+Reachable `c2pa.soft-binding*` assertions retain their exact `alg` and bounded,
+printable block `value` in addition to the normalized vendor label. A block value
+without its algorithm is not surfaced because it cannot be attributed to a
+decoder or registry entry. `com.microsoft.invismark.1` uses that value as the
+pixel-watermark identifier in Microsoft Paint output. An InvisMark soft binding
+keeps the invisible-removal gate fail-safe even when the C2PA asset binding has
+since become invalid, because metadata damage does not prove the pixel carrier
+disappeared. Content-fingerprint soft bindings do not trigger pixel regeneration.
+
 The SDK default enables trust verification but supplies no production trust
 anchors. Consequently, an installation without an explicitly maintained C2PA
 trust bundle reports otherwise valid signer chains as untrusted and keeps their

docs/supported-signals.md

@@ -138,6 +138,18 @@ all-media watermark policy, and current OpenAI C2PA carrying an explicit
 assert SynthID. After provenance metadata is removed, a local negative result
 is still inconclusive.
 
+Microsoft Paint can name `com.microsoft.invismark.1` in a C2PA soft-binding
+assertion. Inspection reports both that exact algorithm and its signed `value`,
+which Paint uses as the identifier carried by the pixel watermark. Photos has a
+parallel local writer path, but no public output sample was available for this
+work. Metadata stripping removes the embedded manifest, not the pixel carrier.
+The project has no validated local InvisMark decoder. Microsoft's official
+[Content Provenance Detection API](https://learn.microsoft.com/en-us/azure/ai-services/content-safety/how-to/how-to-provenance-detection)
+is the external oracle: it reports pixel `Watermark` and embedded `C2PA` results
+separately. The diffusion profiles have not been broadly certified against that
+oracle, so a control-positive, output-negative pair is still a per-file result,
+not a universal guarantee.
+
 For MP4, MOV, and M4V, `video invisible` or the explicit
 `video all --invisible` option can regenerate the video through a VAE and strip
 source metadata. The shipped profile is oracle-certified, but it is not a local
@@ -158,6 +170,7 @@ not a universal clean verdict.
 | Google Gemini | Sparkle | Diffusion regeneration for SynthID | C2PA and related source signals |
 | Google Veo video | Veo diamond and legacy text | Oracle-certified VAE removal for SynthID | C2PA and related source signals |
 | OpenAI image generators | None registered | Diffusion regeneration for supported invisible signals | C2PA and generator provenance |
+| Microsoft Paint and Photos | None registered | External Microsoft oracle for InvisMark; no validated local decoder | Paint C2PA soft-binding algorithm and identifier |
 | Stable Diffusion and SDXL | None registered | Diffusion regeneration; optional open decoder | Embedded parameters and text metadata |
 | FLUX | None registered | Diffusion regeneration; optional open decoder | C2PA for supported sources |
 | Adobe Firefly | None registered | Optional TrustMark Variant P decoder | C2PA |

docs/verification-plan.md

@@ -186,10 +186,14 @@ report recall from the detector-sampled set.
 
 ## Tier D -- external oracles (manual, not automatable here)
 
-SynthID removal cannot be verified locally by design -- no public decoder exists. Each
-vendor has its own oracle and it covers only that vendor's content: `openai.com/verify` for
-OpenAI (more accessible, the automation candidate), the Gemini app for Google (manual,
-rate-limited). A quiet metadata proxy is **not** proof the pixel watermark is gone.
+Proprietary watermark removal cannot be verified locally by design -- no public decoder
+exists. Each vendor has its own oracle and it covers only that vendor's content:
+`openai.com/verify` for OpenAI, the Gemini app for Google, and Microsoft's
+[Content Provenance Detection API](https://learn.microsoft.com/en-us/azure/ai-services/content-safety/how-to/how-to-provenance-detection)
+for InvisMark. The Microsoft API reports `Watermark` and `C2PA` separately. It therefore
+needs a pixel-identical metadata-stripped control: the control must lose `C2PA` while
+remaining `Watermark`-positive before a candidate's negative result can be attributed to
+pixel regeneration. A quiet metadata proxy is **not** proof the pixel watermark is gone.
 
 Scope honestly: this tier certifies strength floors on a handful of images per vendor, and
 that is all it can do. See `docs/synthid.md`.

docs/watermarking-landscape.md

@@ -65,7 +65,8 @@ payloads. Removal remuxes either container through ffmpeg with stream copy.
   DWT-DCT decoder only applies when the producing pipeline actually ran its
   encoder and the carrier remains decodable.
 - **Invisible but NOT locally detectable (proprietary, API/oracle only — same wall as SynthID):** Amazon Titan Image Generator + Nova Canvas (Bedrock `DetectGeneratedContent` API), Kakao (new SynthID image adopter, May 2026), NVIDIA Cosmos (SynthID video). No local detector possible; treat like SynthID.
-- **C2PA 2.4 "Durable Content Credentials" (April 2026; verified against the spec) raise the bar for metadata stripping.** 2.4 defines soft bindings (an invisible watermark or a content fingerprint) plus a server-side manifest repository and a new `c2pa.repository-receipt` assertion. Per the spec: "if a C2PA manifest is removed from an asset, but a copy of that manifest remains in a provenance store elsewhere, the manifest and asset may be matched using available soft bindings." So our local `metadata --remove` deletes the *embedded* manifest, but a fingerprint/watermark soft binding can still re-link the image to its manifest in a repository server-side. Stripping the file is becoming necessary-but-not-sufficient against durable provenance. (Our parsers target the stable embedded-manifest format documented in C2PA 2.1 §11; that format is unchanged in 2.4 -- the new pieces are repository/soft-binding infra, not the on-file box layout, so no parser change is implied.) Spec: https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html We now READ the soft-binding `alg` (`C2PA_SOFT_BINDINGS` / `soft_binding_vendors_in`) to name the forensic-watermark vendor, and locally DECODE the one open scheme, Adobe TrustMark (`trustmark_detector`); the rest (Digimarc/Imatag/Steg.AI/...) stay name-only (proprietary decoders).
+- **C2PA 2.4 "Durable Content Credentials" (April 2026; verified against the spec) raise the bar for metadata stripping.** 2.4 defines soft bindings (an invisible watermark or a content fingerprint) plus a server-side manifest repository and a new `c2pa.repository-receipt` assertion. Per the spec: "if a C2PA manifest is removed from an asset, but a copy of that manifest remains in a provenance store elsewhere, the manifest and asset may be matched using available soft bindings." So our local `metadata --remove` deletes the *embedded* manifest, but a fingerprint/watermark soft binding can still re-link the image to its manifest in a repository server-side. Stripping the file is becoming necessary-but-not-sufficient against durable provenance. (Our parsers target the stable embedded-manifest format documented in C2PA 2.1 §11; that format is unchanged in 2.4 -- the new pieces are repository/soft-binding infra, not the on-file box layout, so no parser change is implied.) Spec: https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html We now READ the soft-binding `alg` (`C2PA_SOFT_BINDINGS` / `soft_binding_vendors_in`) to name the forensic-watermark vendor, preserve the structured assertion's signed `value`, and locally DECODE the one open scheme, Adobe TrustMark (`trustmark_detector`); the rest stay name-only unless a compatible decoder is independently verified.
+- **Microsoft Paint and Photos InvisMark (reverse-engineered 2026-08-20):** Paint receives a per-generation GUID from remote prompt moderation, embeds it into locally generated pixels, and records the same value in `c2pa.soft-binding` under `com.microsoft.invismark.1`. The C2PA soft-binding registry independently identifies that algorithm as Microsoft Responsible AI InvisMark for image and video. Paint's 144-bit writer framing does not match the public repository's 100-bit pretrained checkpoint interface, so compatibility is not assumed. The parser reports the signed identifier; there is no validated local pixel decoder. Microsoft's external Content Provenance Detection API is the removal oracle because it reports `Watermark` separately from `C2PA`; a metadata-stripped, pixel-identical control must remain watermark-positive before an output-negative result is attributed to pixel removal. Sources: https://xusheng.dev/posts/reversing/mspaint_invisible_watermark/main/, https://github.com/c2pa-org/softbinding-algorithm-list/blob/main/softbinding-algorithm-list.json, and https://learn.microsoft.com/en-us/azure/ai-services/content-safety/how-to/how-to-provenance-detection
 - **Built in the dated batch:** soft-binding vendor detection, IPTC Photo
   Metadata AI-disclosure fields, C2PA detection and stripping for supported
   ISOBMFF video, the optional Adobe TrustMark decoder, and temporally stabilized