App Registration Federated Credentials Using Custom Claim Expression Causes Internal Server Error #1359

Describe the bug

I am attempting to filter through all of my App Registrations that have Federated Credentials configured, but am getting an Internal Server Error from the API whenever a credential uses the Claim Matching Expressions functionality instead of an explicit subject value. For example, this is a problematic credential for the API:

This results in the following response data from the API which the SDK cannot handle properly as it's not valid JSON:

{
  "@odata.context":"https://graph.microsoft.com/v1.0/$metadata#applications('<application id>')/federatedIdentityCredentials",
  "value":[
    {
      "id":"<credential id>",
      "name":"debug_v2",
      "issuer":"https://token.actions.githubusercontent.com"{"error":{"code":"InternalServerError","message":"The property 'subject[Nullable=False]' of type 'Edm.String' has a null value, which is not allowed.","innerError":{"date":"2025-09-17T21:05:59","request-id":"f1ffe8e1-f229-4ba1-83e6-69c64046e4a5","client-request-id":"f1ffe8e1-f229-4ba1-83e6-69c64046e4a5"}}}

You'll note that the value attribute would contain multiple other credentials (there are 3 on this app registration), but because of this error they're not visible at all. I don't think this is an issue with the SDK specifically, rather the Graph API it's using, but this seems like a reasonable place to report the issue since it's preventing SDK functionality from working properly.

Expected behavior

Claims matching expressions are supported in the JSON response for Federated Credentials

How to reproduce

GraphServiceClient(credentials=<credential>).applications.by_application_id(app_object_id).federated_identity_credentials.get()

where the app registration being queried has at least 1 federated credential using the "claims matching expression" feature.

SDK Version

1.2.0

Latest version known to work for scenario above?

No response

Known Workarounds

Haven't been able to find a way around other than finding the data manually through the portal

Debug output

</details>


### Configuration

_No response_

### Other information

_No response_