[SCIM] PatchRequest for complex properties returns incorrect response structure

[dimOk00]

Hi ✋

Description

When making a SCIM PatchRequest to update complex properties using dot notation (e.g., name.givenName), the response structure is incorrect. The complex property is flattened instead of maintaining the proper nested object structure as defined in the SCIM schema.

Steps to Reproduce

1. Send a SCIM PATCH request to update complex properties using dot notation
2. Observe the response structure

Expected Behavior

The response should maintain the proper nested object structure for complex properties as defined in the SCIM User schema, with name as a complex attribute containing givenName and familyName.

Actual Behavior

The response flattens the complex property, returning givenName as a top-level attribute instead of nested within the name object. The familyName operation appears to be ignored entirely.

Request Example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "name.givenName",
      "value": "Patched"
    },
    {
      "op": "replace", 
      "path": "name.familyName",
      "value": "User"
    }
  ]
}

Actual Response

{
  "id": "c700e971-a1d0-4781-9ff2-948746c9f9e4",
  "givenName": "Patched",
  "groups": [],
  "emails": [],
  "meta": {
    "resourceType": "User",
    "created": "2025-08-14T12:15:51.3840915",
    "lastModified": "2025-08-14T12:18:02.5453875Z",
    "version": "2",
    "location": "http://localhost/scim/e5c0cb5d-28b7-4167-88e6-a275cf94db33/Users/c700e971-a1d0-4781-9ff2-948746c9f9e4"
  },
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"]
}

Expected Response

{
  "id": "c700e971-a1d0-4781-9ff2-948746c9f9e4",
  "name": {
    "givenName": "Patched",
    "familyName": "User"
  },
  "groups": [],
  "emails": [],
  "meta": {
    "resourceType": "User",
    "created": "2025-08-14T12:15:51.3840915",
    "lastModified": "2025-08-14T12:18:02.5453875Z",
    "version": "2",
    "location": "http://localhost/scim/e5c0cb5d-28b7-4167-88e6-a275cf94db33/Users/c700e971-a1d0-4781-9ff2-948746c9f9e4"
  },
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"]
}

Thanks for your time and consideration in looking into this issue!

[simpleidserver]

Hello,

This is not an issue. By default, the SCIM server is configured not to return the full representation when a modification operation is executed, in order to improve performance.
Sometimes a representation can be very large and take a long time to return — for example, a group with more than 20,000 users.

To always return the full representation, you can set the IsFullRepresentationReturned property to true. This property is available in the SCIMHostOptions:

.AddScim(o =>
{
    o.IgnoreUnsupportedCanonicalValues = false;
    o.IsFullRepresentationReturned = true;
}, true)

KR,

SID

[dimOk00]

Thanks SID for your response! The IsFullRepresentationReturned property really helps me understand the behavior better.

However, I have a question about the response structure when IsFullRepresentationReturned is set to false. Even when returning only the patched properties, shouldn't the response maintain the proper nested object structure as defined in the SCIM schema?

For example, when patching name.givenName and name.familyName, I would expect the response to be structured like this:

{
  "name": {
    "givenName": "Patched",
    "familyName": "User"
  }
}

Or at minimum, preserve the dot notation structure:

{
  "name.givenName": "Patched",
  "name.familyName": "User"
}

Currently, the response flattens the complex attribute to the root level ("givenName": "Patched"), which seems to break the SCIM schema structure regardless of whether it's a full or partial representation.

What are your thoughts on this? Should the schema structure be maintained even in partial responses?

Thanks again for your help!

Best regards

[simpleidserver]

Unfortunately, there was a minor issue in the BuildHierarchicalAttributes operation.
While the representation was correctly saved with the proper structure, the result returned to the client was incorrect.

This issue has been fixed in the master branch.
When an update operation is executed and the IsFullRepresentationReturned flag is set to false, the name.familyName attribute will no longer be returned.
To receive the full representation after an update, you must set IsFullRepresentationReturned to true.

KR,
SID