Re: [scim] [EXTERNAL] Re: Contributors needed for HR schema

Would it make sense to split these into separate items? Defining the HR schema being one piece - possibly into different sub-schemas(is that a word?) for different classes of data -  i.e.: general organizational data vs some set of data that would serve other purposes such as salary data (NOT saying we include that..) for easier boundary lines for applying access control? And then for the second piece, I think this sub-bullet from the charter:

    * Per-attribute schema negotiation

May cover the topics you mentioned on limiting what parts of the schema are available to what parties. Part of why I suggest splitting this apart is that the topic of limiting access to data looks like it aligns with that that charter item, but it's also applicable outside of the HR schema scenario and should be solved separately and then applied across the board.

Does that sound OK, or am I missing something and completely off base..?

Thanks,

Danny

From: Danny Mayer <mayer@pdmconsulting.net>
Sent: Monday, June 20, 2022 1:34 PM
To: Danny Zollner <Danny.Zollner@microsoft.com>; scim@ietf.org
Subject: [EXTERNAL] Re: [scim] Contributors needed for HR schema

I have plenty of experience fetching non-privacy data from HR. The bigger question, as usual is how much do you want to make "public" in other applications and how do you make sure you limit the data that the HR organization is prepared to share with other parts of the company.

Danny
On 6/17/22 4:35 PM, Danny Zollner wrote:
Hi SCIM-ers,

One of the items on the charter for the SCIM working group is to design a human resources-centric schema for SCIM. For this to be successful, we'll need contributors that are knowledgeable on HR and HCM services and concepts. If anyone has background on this area - ideally previously or currently working for an organization involved in this space - and can contribute, please respond to this thread and let us know of your interest.

I've had some discussions with folks more knowledgeable on these sort of things than I am already, and here are a few things I took away from that that I'd like to put out there as ideas up for discussion:

  1.  We should create a new resource, "Worker", rather than make an HR schema on a user resource. HR data is likely to feed into a logic engine of some sort that then ultimately decides what needs to happen, and HR systems generally should not be directly turning HR data into users in other systems without some middle layer.

  2.  Some attributes in this schema may have a finite list of acceptable values - think locations, departments, cost centers. Extending other new resources, i.e.: /CostCenters, may be helpful for discovery's sake to allow a client interacting with an HR/HCM SCIM service provider to GET a list of allowed locations, departments, cost centers, etc.. and more efficiently generate requests where the values of these attributes can be predetermined to be valid or not ahead of an operation to create/update a worker.

Thanks,

Thanks,

Danny Zollner

_______________________________________________

scim mailing list

scim@ietf.org<mailto:scim@ietf.org>

https://www.ietf.org/mailman/listinfo/scim<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7Ca688578c21cb4368843b08da52f3db3f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637913504701608666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=geskFfHmlYs147l2z7JWSmeGkD2rwRJVQq7TE9K97mE%3D&reserved=0>