Add tests to guard client-capability (xms_cc) forwarding in CCA flows

[gladjohn]

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

latest

Web app

Sign-in users

Web API

Protected web APIs (validating tokens)

Token cache serialization

In-memory caches

Description

Code inspection shows that TokenAcquisition never calls WithClientCapabilities() on any MSAL builder

https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web.TokenAcquisition/TokenAcquisition.cs#L795

Reproduction steps

"AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "msidlab4.onmicrosoft.com",
    "ClientId": "<>"
    "ClientCapabilities": [ "cp1" ],
    "ClientCredentials": [
        {
            "SourceType": "CustomSignedAssertion",
            "CustomSignedAssertionProviderName": "OidcIdpSignedAssertion",
            "CustomSignedAssertionProviderData": {
                "ConfigurationSection": "AzureAd2"
            }
        }
    ]

Relevant code snippets

https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web.TokenAcquisition/TokenAcquisition.cs#L795

Regression

Doesn't seem like this ever worked.

Based on investigation

Feature already works (tokens include CP1) and that the PR is strictly test-coverage.

[bgavrilMS]

I think this is a P1, as it invalidates a major scenario (CAE).

[gladjohn]

A closer look showed that ClientCapabilities are already forwarded via ConfidentialClientAppOptions (when merged), so tokens today do include the expected xms_cc claim.

A PR is on the way that adds dedicated tests (unit + integration) to lock this behavior in and prevent future regressions. No functional changes were required.

[jmprieur]

A closer look showed that ClientCapabilities are already forwarded via ConfidentialClientAppOptions (when merged), so tokens today do include the expected xms_cc claim.

A PR is on the way that adds dedicated tests (unit + integration) to lock this behavior in and prevent future regressions. No functional changes were required.

Yes I was pretty surprized.
So it's a no-repro, right?

[gladjohn]

A closer look showed that ClientCapabilities are already forwarded via ConfidentialClientAppOptions (when merged), so tokens today do include the expected xms_cc claim.
A PR is on the way that adds dedicated tests (unit + integration) to lock this behavior in and prevent future regressions. No functional changes were required.

Yes I was pretty surprized. So it's a no-repro, right?

yes, @jmprieur. I confirmed that ClientCapabilities are merged into ConfidentialClientApplicationOptions and forwarded to MSAL, so the CP1 claim shows up as expected.

PR #3351 adds unit + integration tests to lock this in and prevent regressions—no product code changes needed.

[jmprieur]

So the title of the issue is mis-leading?
the repro steps are not repro steps?
You mis-understood the code and claimed to have a P1 whereas it's a non-issue?

(I agree with adding tests for sure, but that's not what the title is about)

[gladjohn]

You’re right. The original title and “Steps to Reproduce” no longer reflect the reality

What I’m doing to clean this up

• Retitle the issue to something like “Add tests to guard client-capability (xms_cc) forwarding in CCA flows.”

• Update the description to note that the feature already works (tokens include CP1) and that the PR is strictly test-coverage.

• Drop the P1 / bug labels and re-label as tests / quality‐gate.

That should keep the repo history clear and let reviewers focus on the new tests rather than a non-existent defect.

Appreciate the call-out and for quick approvals.