AdminT.03275 (Customer) asked a question.
Okta does not conform to Core 2.0 SCIM Schema with regards to the "Group" resource's "members" attribute
Okta does not conform to the Core 2.0 SCIM schema of "Group" resources when specifying the "members" attribute.
In SCIM 2.0, "members" is a multi-valued attribute with sub-attributes "value", "$ref", and "type". However, Okta still specifies "members" as a multi-valued attribute with sub-attributes "value" and "display". Okta's specification of the "members" attribute is SCIM 1.1 compliant, but not SCIM 2.0 compliant.
Can this SCIM 2.0 compliance issue be fixed in Okta?
I'm not seeing "type" as you describe in the SCIM 2.0 docs for "group-->members". To me it looks like "value" and "display" are found in both Okta and SCIM specs. Only "$ref" is found only in the SCIM spec and not in Okta but it probably is not needed since the "value" contains the GUID and you could presume the URL if needed.
Okta
https://developer.okta.com/docs/reference/scim/scim-20/#retrieve-specific-groups
Cross-domain Identity Management: Core Schema
See section 8.4 ---> https://www.rfc-editor.org/rfc/rfc7643
Cross-domain Identity Management: Protocol
See page 40 ---> https://www.rfc-editor.org/rfc/rfc7644
For context, the "type" field is defined by SCIM 2.0 to help us distinguish between Group and User resources as members of a Group.
After viewing RFC7643 again, there looks like a conflict of examples regarding the Group resource. The conflict is that this resource's corresponding schema representation example in section 8.7.1 (page 68 to view the "members" attribute definition), specifies that the "members" attribute has only sub-attributes "value", "$ref", and "type"; "display" is not mentioned here.
I do not fully understand why the Group resource JSON representation example in section 8.4 does not accurately align with the Schema Representation example in section 8.7.1 in terms of the "members" attribute, but we think that the Schema Representation section should be referenced over the Group Representation in JSON Format Example section and other JSON examples, because the former section is meant to specify the attributes and sub-attributes that constitute a resource. Thoughts?
Also just to clarify, we do not need "$ref" and "type" fields to be sent in Group-related requests, since we can just presume these like you said, but ideally we should stop sending the "display" attribute because it is not specified in the Schema Representation section of RFC7643.