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

[Jennifer Schreiber <[e-mail]>]

Hi Phil – no prob.

This makes sense theoretically. I still have two use case:

  *   A support tech would use an errorCode or additional error details (such as a timestamp, correlation id, longform error detail etc.) to communicate with the SCIM server support human to debug.
  *   A SCIM client may want metrics on the errors often occurring for their requests where SCIM detail would be too granular.

I am mostly finding that the current SCIM error message is too vague, making challenging for the SCIM client to easily (machine or human) debug what is going on with their failed requests. We’ve had to rely on concatenating the error detail to put more relevant information into the response which is less than ideal.



From: Phillip Hunt <[e-mail]>
Date: Monday, January 22, 2024 at 2:52 PM
To: Jennifer Schreiber <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [External Sender] Re: [scim] Error extensibility in SCIM - meeting follow up
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7643*section-3.3__;Iw!!Iz9xO38YGHZK!6D6SrM5Foas-icEjP3y9gveFMQZmfYweHP_NT89JpkM3IiHNprSv_u1objVF30Hks_nADJD9soHVSaKjusq67NXECuUiPg$>? Can error messages, as well as the other scim messages defined in Section 8.2 of RFC 7644<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7644*section-8.2__;Iw!!Iz9xO38YGHZK!6D6SrM5Foas-icEjP3y9gveFMQZmfYweHP_NT89JpkM3IiHNprSv_u1objVF30Hks_nADJD9soHVSaKjusq67NUEork4lw$> be extended?

Section 3.12 of RFC 7644<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7644*section-3.12__;Iw!!Iz9xO38YGHZK!6D6SrM5Foas-icEjP3y9gveFMQZmfYweHP_NT89JpkM3IiHNprSv_u1objVF30Hks_nADJD9soHVSaKjusq67NU-hbJA7w$> 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<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/scim__;!!Iz9xO38YGHZK!6D6SrM5Foas-icEjP3y9gveFMQZmfYweHP_NT89JpkM3IiHNprSv_u1objVF30Hks_nADJD9soHVSaKjusq67NUjA2dxdw$>