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

[Danny Zollner <[e-mail]>]

Apologies for the several month delay.

Danny Mayer: I don't think the angle that you are approaching this from is the same as the one I am. I'd argue it isn't the problem that was being thought of when the item mentioning an enhanced schema to support exchanging of human resources data was added to the charter, either.

Looking at this from the perspective of consuming HR data from multiple HR sources, the #1 problem is that every HR source today has its own API with its own schema. Most HR providers have not adopted SCIM, and I believe the primary contributing factor is the lack of an appropriate schema. The SCIM 2.0 user schema (core/enterprise) doesn't overlap enough with the types of information present in HR systems. Creating a set of schemas for those that consume HR data would help with the problem of sending HR-related data to other systems but doesn't solve the problem I described.

I took the name "Worker" from the implementations of some of the most prominent HR systems. A worker is typically a higher-level classification that represents full-time employees, contractors, interns, and other types of workers. The status of the employment is defined in an attribute on the object.


  *   Workday has a Get_Worker API (Cannot locate documentation - may be customer only)
  *   Oracle Fusion Cloud HCM has a Workers API (https://docs.oracle.com/en/cloud/saas/human-resources/22c/farws/api-workers.html)
  *   ADP has a Workers API (https://developers.adp.com/articles/api/hcm-offrg-wfn/hcm-offrg-wfn-hr-workers-v2-workers/apiexplorer)

Also, to address this: '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.' - I think the question of data security is an important one but should be taken on separately from the discussion of an HR schema, as the work here would be likely agnostic to any given schema. I'll also say that currently, responsibility for restricting access to sensitive data rests on the SCIM service provider.

Specific to data security concerns regarding an HR schema, I think input is needed from players in the HR/HCM industry on if it would be wise to include extremely sensitive information such as salaries and social security numbers in a worker resource. Looking at APIs for the Oracle and ADP APIs I mentioned above, they have separate salaries/compensation APIs. This leads me to think that salaries should not be included on the Worker resource, and if exposed via SCIM would perhaps be better suited for a separate resource.

Thanks,

Danny Zollner (He/Him)

From: scim <[e-mail]> On Behalf Of Danny Mayer
Sent: Wednesday, June 22, 2022 5:50 PM
To: Danny Zollner <[e-mail]>; [e-mail]
Subject: Re: [scim] [EXTERNAL] Re: Contributors needed for HR schema


I think you have it the wrong way round. The schemas need to be targeted at the applications that need to use it. Let me lay out at least 4 different types of target applications. There may be more but that's what I can think of off the top of my head. Note that I didn't like the use of the word 'Worker' and used 'Resource' instead though that may be too vague for SCIM. Suggestions welcome. Note that a 'Resource' may be an employee, contractor, intern, board member, auditor, etc. Each schema would need to be clear on the type of resource being referenced.
1) Authorization applications

Examples of this are Active Directory, Credential Authorization, Card Readers. There are others where authorizations for a resource needs to be configured. Information that needs to be provided include the type of resource, various groups like department and division, office location, office email, etc. Card Readers are often forgotten as needing some information as some office areas, or even building may be restricted, either by type of person or the hours.

2) Payment and benefits systems

These require personal information about a person, including their national ID, home address, banking information, etc. needed to process payroll. In addition, benefits like insurance require items like beneficiaries and dependents, home address, etc. Savings plans require similar information. This is usually only for Employees, but there can be exceptions for contractors performing work with these systems.

3) Other applications

These include requirements like their general information of their cost center, profit center, manager, division, department, etc. Examples of this are Timesheet and Expense applications. Usually Employees and Contractors need access to these systems to enter their hours and expenses. In addition some people in the finance department may require some sort of 'super' access to these systems to perform their job.

4) Ticketing applications

These systems don't need any special information about a person but there are likely to be contractors involved in helping with the tickets and need additional access.

I hope this helps in getting this rolling.

Danny
On 6/20/22 7:41 PM, Danny Zollner wrote:
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 <[e-mail]><mailto:[e-mail]>
Sent: Monday, June 20, 2022 1:34 PM
To: Danny Zollner <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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%7C6e92102c73904396c43e08da54a19917%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915350325187932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3fMCqnAL8V7%2BDGHLommvL9UNVAUalA4Fxc%2F%2Bq2ZtNrU%3D&reserved=0>