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

[Danny Zollner <[e-mail]>]

I looked at the spec some months ago specifically to figure out a similar question on extending the schema of these urn:ietf:params:scim:api:.. responses with additional attributes. This snippet from 7644 section 3.1 served as my answer at the time:

'As SCIM protocol messages are fixed and defined by SCIM specifications and registered extensions, SCIM message schemas using the above prefix URN SHALL NOT be discoverable using the "/Schemas" endpoint.'

Since scimType is stated to be optional I think you're clear to return a status 400 and use the value of the detail attribute to pass additional information even if it doesn't align to a scimType / description in table 9 of 7644 (part of section 3.12). I'd be interested in further discussions on extending API messages, so I'll try to make it to the next few interim meetings.

Thanks,

Danny Zollner

From: scim <[e-mail]> On Behalf Of Jennifer Schreiber
Sent: Wednesday, January 17, 2024 10:30 AM
To: [e-mail]
Subject: [EXTERNAL] [scim] Error extensibility in SCIM - meeting follow up

Some people who received this message don't often get email from jennifer.winer=[e-mail]<mailto:jennifer.winer=[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
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