How do I construct encryptedRequest for KeyCredential.RequestDeriveSharedSecretAsync?

Hi @Matthew Sepanik , 

Thanks for the detailed write up. 

First, the encryptedRequest format is not publicly documented 

I checked the reference pages and there is no published specification: 

• KeyCredential.RequestDeriveSharedSecretAsync 
• KeyCredential.RetrieveAuthorizationContext 
• KeyCredential class 

Both methods list encryptedRequest as an IBuffer with no description, no remarks, and no example, and both have a blank Description cell in the class method table while RetrievePublicKey, GetAttestationAsync, and RequestSignAsync do not. Both pages carry the prerelease banner and apply only to WinRT Build 26100 and 28000. 

So, I cannot give you a verified construction example, and I would recommend against calling the method with guessed buffer contents. 

Second, yes, the supported workflow requires a VBS enclave.The ChallengeResponseKind enum has exactly one member, VirtualizationBasedSecurityEnclave, so there is no non enclave option to select. 

 The VBS Enclave SDK user bound key sample creates Windows Hello protected encryption keys sealed to the enclave, with the key generated inside the VTL1 enclave and never leaving it in plaintext. The Rust binding crate in the same repo calls RequestCreateAsync2 with an enclave handle and ChallengeResponseKind::VirtualizationBasedSecurityEnclave. The request buffer is assembled on the enclave side, and no standalone helper is published for building it outside that context. 

The prerequisites are substantial: 

• OS: Windows 11 Build 26100.2314 or later, or Windows Server 2025 or later, with VBS/HVCI enabled 
• SDK:Windows SDK 10.0.26100.0 or later with ucrt_enclave, plus veinterop.lib from 10.0.26100.7463 or later 
• Toolchain: Visual Studio 2022 with the MSVC enclave toolchain 
• Signing: a code signing certificate for VBS enclaves (Trusted Signing) 

The signing requirement in particular is worth validating before you invest in this path. I would also confirm VBS enclave availability on your specific Windows 11 Home ARM64 target. 

And finally, unpackaged desktop apps, and what to evaluate instead 

WinRT APIs that require package identity are supported only in desktop apps packaged with MSIX, per WinRT APIs not supported in desktop apps. Windows Hello key credential calls from a non packaged Win32 app have been reported to fail with 0x80073D54 (process has no package identity). If you want identity without moving to full MSIX, see packaging with external location. 

Also worth noting: ApiInformation.IsMethodPresent only tells you the method exists in metadata on that machine. It does not tell you the call is supported in your process context. 

Supported alternatives for your scenario: 

• User approval gesture before a crypto operation: UserConsentVerifier. In a desktop app, retrieve the HWND and call RequestVerificationForWindowAsync through the UserConsentVerifierInterop class rather than RequestVerificationAsync. 
• Hello backed key operation with a documented flow: KeyCredentialManager.RequestCreateAsync with RequestSignAsync. 
• Protecting the generated key at rest: user scoped DPAPI, CryptProtectData caveat on that last point so there is no confusion. DPAPI plus a separate UserConsentVerifier check is not equivalent to Hello authorized decryption. Approval enforcement lives in your application logic rather than in the cryptography, so decryption is not cryptographically dependent on the approval succeeding. If your requirement is that the key cannot be released without a Hello gesture, that gap matters. 

On your original requirement, a confirmed request construction workflow is not available publicly today.  

Hope these information help. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. 

Thank you.