WebAuthNPluginPerformUserVerification2: binding between pwszDisplayHint, pbBufferToSign, and returned response

Nguyễn Văn Toàn 0 Reputation points
2026-09-04T04:47:26.65+00:00

We are evaluating WebAuthNPluginPerformUserVerification2 / WEBAUTHN_PLUGIN_USER_VERIFICATION_REQUEST_2 for a high-assurance human transaction-confirmation workflow.

The current Microsoft documentation states that:

  • pwszDisplayHint is the text hint displayed on the Windows Hello prompt.
  • pbBufferToSign is an optional custom buffer that the user-verification key signs.
  • The API does not hash pbBufferToSign before signing it.
  • WebAuthNPluginPerformUserVerification2 returns a response buffer through ppbResponse.

We need clarification on two security properties that are not explicit in the current API documentation.

Q1 — Display-to-sign binding

Does Windows Hello / WebAuthNPluginPerformUserVerification2 enforce any cryptographic or platform-level binding between the exact content actually rendered to the user through pwszDisplayHint and the bytes supplied in pbBufferToSign?

For example, if a caller supplies:

  • pwszDisplayHint = "Transaction A"
  • pbBufferToSign = bytes representing Transaction B

does Windows detect or prevent this mismatch, or will it display A while signing B?

If a binding does exist, please describe:

  1. what exact representation of pwszDisplayHint is bound to the signed data;
  2. whether the entire display hint is guaranteed to be presented and reviewable before user confirmation;
  3. applicable length, truncation, wrapping, scrolling/pagination, and Unicode limits;
  4. whether the guarantee still holds against a compromised or malicious calling application.

If Windows does not provide such a binding, a clear confirmation of that fact would also answer our question.

Q2 — Response verification and exact-request correlation

What is the authoritative verification model for the ppbResponse returned by WebAuthNPluginPerformUserVerification2 when pbBufferToSign is supplied?

Specifically:

  1. Which exact bytes are cryptographically authenticated by the returned response?
  2. What signature/encoding format and algorithm are used?
  3. How is the corresponding public verification key obtained?
  4. Is there a documented procedure or API for independently verifying the response?
  5. Does successful verification prove confirmation of the exact pbBufferToSign supplied for that request, and can that result be reliably correlated to pGuidTransactionId?
  6. Does the response contain or cryptographically bind any representation of the text that was actually rendered from pwszDisplayHint?

We are not looking for a general Windows Hello overview. A concise authoritative answer to Q1 and Q2, or links to Microsoft technical documentation defining these guarantees, would be sufficient.

This clarification is needed to determine whether the API can serve as a trusted exact-operation human-confirmation primitive rather than only a user-presence/user-verification mechanism.

Thank you.We are evaluating WebAuthNPluginPerformUserVerification2 / WEBAUTHN_PLUGIN_USER_VERIFICATION_REQUEST_2 for a high-assurance human transaction-confirmation workflow.

The current Microsoft documentation states that:

  • pwszDisplayHint is the text hint displayed on the Windows Hello prompt.
  • pbBufferToSign is an optional custom buffer that the user-verification key signs.
  • The API does not hash pbBufferToSign before signing it.
  • WebAuthNPluginPerformUserVerification2 returns a response buffer through ppbResponse.

We need clarification on two security properties that are not explicit in the current API documentation.

Q1 — Display-to-sign binding

Does Windows Hello / WebAuthNPluginPerformUserVerification2 enforce any cryptographic or platform-level binding between the exact content actually rendered to the user through pwszDisplayHint and the bytes supplied in pbBufferToSign?

For example, if a caller supplies:

  • pwszDisplayHint = "Transaction A"
  • pbBufferToSign = bytes representing Transaction B

does Windows detect or prevent this mismatch, or will it display A while signing B?

If a binding does exist, please describe:

  1. what exact representation of pwszDisplayHint is bound to the signed data;
  2. whether the entire display hint is guaranteed to be presented and reviewable before user confirmation;
  3. applicable length, truncation, wrapping, scrolling/pagination, and Unicode limits;
  4. whether the guarantee still holds against a compromised or malicious calling application.

If Windows does not provide such a binding, a clear confirmation of that fact would also answer our question.

Q2 — Response verification and exact-request correlation

What is the authoritative verification model for the ppbResponse returned by WebAuthNPluginPerformUserVerification2 when pbBufferToSign is supplied?

Specifically:

  1. Which exact bytes are cryptographically authenticated by the returned response?
  2. What signature/encoding format and algorithm are used?
  3. How is the corresponding public verification key obtained?
  4. Is there a documented procedure or API for independently verifying the response?
  5. Does successful verification prove confirmation of the exact pbBufferToSign supplied for that request, and can that result be reliably correlated to pGuidTransactionId?
  6. Does the response contain or cryptographically bind any representation of the text that was actually rendered from pwszDisplayHint?

We are not looking for a general Windows Hello overview. A concise authoritative answer to Q1 and Q2, or links to Microsoft technical documentation defining these guarantees, would be sufficient.

This clarification is needed to determine whether the API can serve as a trusted exact-operation human-confirmation primitive rather than only a user-presence/user-verification mechanism.

Thank you.

Windows development | Windows API - Win32
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tony Thach (WICLOUD CORPORATION) 1,120 Reputation points Microsoft External Staff Moderator
    2026-09-04T05:42:48.91+00:00

    Hi  @Nguyễn Văn Toàn , and thanks for posting your question. 

    Based on the currently published Microsoft API documentation, the requested guarantees are not defined as part of the public contract for WebAuthNPluginPerformUserVerification2.

    Q1: Display-to-sign binding

    WEBAUTHN_PLUGIN_USER_VERIFICATION_REQUEST_2 documents pwszDisplayHint as the text shown in the Windows Hello prompt and pbBufferToSign as the optional buffer to be signed. However, it does not state that Windows:

    • Compares the displayed text with pbBufferToSign.
    • Cryptographically binds pwszDisplayHint, or its rendered representation, to the signature.
    • Rejects a request that displays “Transaction A” while signing bytes for “Transaction B.”
    • Guarantees complete visibility or defines security-relevant behavior for truncation, scrolling, wrapping, Unicode normalization, bidirectional text, or confusable characters.

    Therefore, the public documentation does not establish a WYSIWYS guarantee or protection against a malicious caller that controls both values. This does not prove that no internal association exists. It means that such an association is not documented as a supported security property.

    WEBAUTHN_PLUGIN_USER_VERIFICATION_REQUEST_2 structure

    Q2: Response verification and correlation

    WebAuthNPluginPerformUserVerification2 returns an opaque response through ppbResponse and pcbResponse. WebAuthNPluginGetUserVerificationPublicKey provides the associated user-verification public-key buffer.

    The published documentation does not normatively specify:

    • The complete byte sequence authenticated by ppbResponse.
    • The signature algorithm, parameters, or encoding.
    • The public-key encoding.
    • A supported procedure or API for independently verifying the response.
    • Whether pGuidTransactionId is included in the cryptographically authenticated data.
    • Whether the response contains or binds the text actually rendered from pwszDisplayHint.

    Although pGuidTransactionId associates the user-verification request with the corresponding plugin operation at the API level, the documentation does not say that this identifier is cryptographically included in the returned response.

    WebAuthNPluginPerformUserVerification2 function

    WebAuthNPluginGetUserVerificationPublicKey function

    WebAuthNPluginFreeUserVerificationResponse function

    WEBAUTHN_PLUGIN_OPERATION_REQUEST structure

    The available public documentation is insufficient to confirm that this API provides exact-operation human confirmation, display-to-sign binding, or cryptographic correlation among pwszDisplayHint, pbBufferToSign, pGuidTransactionId, and ppbResponse.

    An authoritative answer about the actual implementation requires confirmation from the Windows WebAuthn product team, specifically covering the signed-data construction, key and response formats, verification procedure, transaction-ID binding, display binding, and rendering guarantees. Until those properties are officially documented or confirmed, they should not be assumed as guarantees of the supported API contract.

    If this instruction is applicable to your situation, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.  

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.