Skip to content

Fix behavior when patch removes null uneditable fields #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

azmeuk
Copy link
Contributor

@azmeuk azmeuk commented Jul 27, 2025

A mutability error should be raised when deleting read only and immutable fields, even if they are empty in the first place.

@azmeuk azmeuk added the bug Something isn't working label Jul 27, 2025
@azmeuk azmeuk force-pushed the empty-field-deletion branch from cd63efc to f3f6080 Compare July 27, 2025 13:35
@ccoors
Copy link
Collaborator

ccoors commented Jul 27, 2025

This is one of the places where the spec unfortunately isn't very clear.

RFC 7644, Section 3.5.2.2

If an attribute is removed or becomes unassigned and is defined as a required attribute or a read-only attribute, the server SHALL return an HTTP response status code and a JSON detail error response as defined in Section 3.12, with a "scimType" error code of "mutability".

  • is removed -> No, because it wasn't there to begin with
  • becomes unassigned -> No, it was unassigned before

It really depends on where the implicit parentheses on that sentence are.

  • If an attribute (is removed or becomes unassigned) and (is defined as a required attribute or a read-only attribute) -> no error
  • If an attribute is removed or (becomes unassigned and is defined as a required attribute) or a read-only attribute -> error

I opted for the robustness principle ("be conservative in what you do, be liberal in what you accept from others"), so not raising an error since that would just potentially break some clients without providing any actual benefit.

@azmeuk
Copy link
Contributor Author

azmeuk commented Jul 27, 2025

Indeed, I am not 100% convinced by myself here :) I was motivated by RFC7644 §3.5.2 which sounds very general and don't make special cases for empty values:

Each operation against an attribute MUST be compatible with the
attribute's mutability and schema as defined in Sections 2.2 and 2.3
of [RFC7643]. For example, a client MUST NOT modify an attribute
that has mutability "readOnly" or "immutable".

But, is removing/nulling modifying?

I opted for the robustness principle ("be conservative in what you do, be liberal in what you accept from others"), so not raising an error since that would just potentially break some clients without providing any actual benefit.

Sounds fair, and in the end this is not a very important topic because data is not edited either way.

Maybe I'll ask on the SCIM mailing list to see what is the proper interpretation for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants