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

[Phillip Hunt <[e-mail]>]

One of the requirements when you are cross-domain is that schema rules may be different. In general SCIM does not return errors on POST and PUT operations because one or more attributes cannot be accepted.

The lack of exact “compliance” (the result is not what was requested) could be for any number of reasons:
* formatting (e.g. the scim service provider normalized the format of a telephone number or email)
* mutability (the attribute is not modifiable by the client because the attribute is readOnly or immutable (settable once)
* not defined (the service provider does not support or understand the attribute)

None of the above may cause an error.

In this scenario, the correct way to find out what is going on is to query the /Schemas endpoint of the SCIM Service Provider.

Phil
[e-mail]






> On Jan 25, 2024, at 10:43 AM, Sehgal, Anjali <[e-mail]> wrote:
> 
> Just to add on to that discussion,
>  
> I want to understand what’s the view on Error Schema Extensions.
> Suppose a SCIM server wants to improve on error messages returned how should they go about it?
> Update the description with new error? This can break existing SCIM clients who may have built some logic around the text returned.
> Release a new API version?
> Add a schema extension and allow SCIM clients to gradually transfer to using the extended error schema description field?
>  
> If there are any other mechanisms, please feel free to add.
>  
> Thanks
> Anjali.
>  
> From: scim <[e-mail] <mailto:[e-mail]>> on behalf of Jennifer Schreiber <jennifer.winer=[e-mail] <mailto:jennifer.winer=[e-mail]>>
> Date: Thursday, January 25, 2024 at 1:29 PM
> To: Phillip Hunt <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [scim] [External Sender] Re: Error extensibility in SCIM - meeting follow up
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
>  
> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.
> 
>  
> 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$>