Re: [scim] Error extensibility in SCIM - meeting follow up

[Phillip Hunt <[e-mail]>]

Jennifer,

Sorry for not getting back to this sooner. This is important. 

First, I will just zero in on your example (this may not answer your question about extending errors):

In SCIM, the expected behavior is to ignore read-only attribute updates in most cases. The best description of this is probably within the SCIM PUT.  The intent was that a relatively simply client (eg. javascript) could do a GET, change a value, and then do PUT to put the reosurce back. The value of PUT was to avoid having to pay attention to mutability.

The mutability error does apply to PATCH when the intent by the client is to “target" a read-only attribute. 

With that said, if a client (or more likely a support tech) wants to know why an attribute isn’t updating, the schema endpoint is supposed to report the actual mutability.  

==> the reason this was done was that the collective experience of the WG at the time was that X.500 and LDAP were far too fragile by throwing errors on everything didn’t line up perfectly.  The consensus at the time was to follow Postel’s Law (aka the Robustness Principle), which boiled down meant that SCIM servers should accept requests that are understood (but not perfect), and the client must accept the response (disclosure:  I understand many in the IETF have ‘moved on’ from favouring ‘robustness'.

This use case is an example where this robustness plays out. A client doing a PUT has a bunch of attriibutes that can’t be modified but one or two that can. The server accepts the requests and updates the modified fields.  The final state is returned to the client which tells the client what was actually accepted.

—> In this way SCIM avoids the need for a lot of complex signalling and error reporting.

Let me know if this answers your question.  Or did you still have another use case for a detailed error?

Phil
[e-mail]






> On Jan 17, 2024, at 8:29 AM, Jennifer Schreiber <jennifer.winer=[e-mail]> wrote:
> 
> Thanks everyone for a great discussion yesterday at the meeting. We discussed error handling as relevant to scim events draft and RFC 7644.
>  
> Mainly, the big question that came up:
> Is there any extensibility method for the error messages ("urn:ietf:params:scim:api:messages:2.0:Error"), similar to Section 3.3 of RFC 7643 <https://datatracker.ietf.org/doc/html/rfc7643#section-3.3>? Can error messages, as well as the other scim messages defined in Section 8.2 of RFC 7644 <https://datatracker.ietf.org/doc/html/rfc7644#section-8.2> be extended?
>  
> Section 3.12 of RFC 7644 <https://datatracker.ietf.org/doc/html/rfc7644#section-3.12> is a bit vague about the matter.
>  
> This came up for my internally, as the error message is not meeting my implementation needs. We're requiring an additional field, errorCode. Anjali also mentioned the need for an jsonPath field.
>  
> During the meeting, we talked through a couple ideas (that I will review in the next meeting) such as below, but we kept coming back to the same extensibility question. I wanted to open up the discussion here prior to the meeting.
>  
> ```
>    {
>      "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error", "urn:ietf:params:scim:api:extension:messages:2.0:AdvancedError"],
>      "scimType":"mutability"
>      "detail":"Attribute 'id' is readOnly",
>      "status": "400"
>      "urn:ietf:params:scim:api:extension:messages:2.0:AdvancedError": {
>          "errorCode": "ABC-1235"
>      }
>    }
> ```
>  
> Thanks,
> Jen
> _______________________________________________
> scim mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/scim