PasskeyManager: is the operation-request signature construction the actual v1 contract, or just what this sample does

We emailed fido-dev@microsoft.com about this on 2026-09-04 and again on 2026-09-11. No reply either time. microsoft/webauthn has issues and discussions turned off, so this is the only open channel left.

We're building a third-party plugin against the v1 WebAuthn plugin APIs and can't find documentation for how WEBAUTHN_PLUGIN_OPERATION_REQUEST is supposed to be signed and verified. We've been reading it off this sample instead, but a sample isn't a contract, and it already changed once: the September 2026 update switched the sample's padding from PKCS#1 to PSS.

What the sample currently does: signs the raw encoded request bytes, nothing else appended. Hashes with SHA-256, picks padding by reading the public key blob type (PSS for RSA, otherwise falls through to ECDSA). transactionId isn't part of what gets signed.

Three questions:

1. Is that construction the actual v1 requirement, or just how this sample happens to do it?
2. Is the cancel request's signature field supposed to be checked, or is cancellation meant to be unauthenticated?
3. Since transactionId isn't signed, is there any platform guarantee against replaying an operation request, or is that entirely on the plugin?

If there's a better place to ask, point us there.

The sample's WEBAUTHN_PLUGIN_OPERATION_REQUEST signing path and the v1 WebAuthn plugin API are the starting points; compare the current raw-request, SHA-256, padding, cancellation, and transactionId behavior with any repository documentation. Done requires a maintainer-confirmed contract covering signing, cancellation verification, and replay guarantees, then documenting it.