Native AttestationClientLib (MAA) logs are not bridged into the MSAL logger — invisible in verbose logs

[gladjohn]

Library version

Microsoft.Identity.Client.KeyAttestation IMDSv2 mTLS PoP attestation flow.

Expected behavior

With MSAL verbose logging enabled (.WithLogging(...)), native AttestationClientLib.dll diagnostics (including the MAA failure reason) should appear in the MSAL log stream.

Actual behavior

MSAL verbose logs are captured, but MAA / native attestation logs are absent. They go to a separate sink and never reach the MSAL ILoggerAdapter, so the actual attestation failure reason cannot be diagnosed from collected MSAL logs.

Root cause

• src/client/Microsoft.Identity.Client.KeyAttestation/Attestation/AttestationClient.cs registers the native log callback as AttestationLogger.ConsoleLogger.
• src/client/Microsoft.Identity.Client.KeyAttestation/Attestation/AttestationLogger.cs writes those lines to System.Diagnostics.Trace (Trace.WriteLine), not the MSAL ILoggerAdapter. With no TraceListener attached, they go nowhere visible.
• PopKeyAttestor.AttestCredentialGuardAsync has the MSAL logger but never passes it to new AttestationClient(), so no bridge exists.

Impact

Diagnosability: attestation failures are effectively un-debuggable from standard MSAL logs — the actual MAA reason (e.g. a PolicyEvaluationError deny) is only emitted on the native Trace sink.

Proposed fix

• Add an ILoggerAdapter overload to AttestationClient and forward it from PopKeyAttestor.
• Bridge native LogFunc levels to MSAL (Error→Error, Warn→Warning, Info→Info, Debug→Verbose), gated on IsLoggingEnabled, exception-safe, keeping a strong reference to the delegate for the native callback lifetime; fall back to Trace when no logger is supplied.

Related

Companion issue #6079: KeyGuard attestation failure is silently swallowed (empty attestation token sent to IMDS instead of throwing). This logging gap is why that failure is hard to diagnose.