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

[Danny Mayer <[e-mail]>]

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]>
> *Sent:* Monday, June 20, 2022 1:34 PM
> *To:* Danny Zollner <[e-mail]>om>; [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]
>
>     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>
>