Re: [scim] [EXTERNAL] Re: Contributors needed for HR schema
Danny Mayer <mayer@pdmconsulting.net> Wed, 22 June 2022 22:50 UTC
Return-Path: <mayer@pdmconsulting.net>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 694C2C164778
for <scim@ietfa.amsl.com>; Wed, 22 Jun 2022 15:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.674
X-Spam-Level:
X-Spam-Status: No, score=-3.674 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1,
NICE_REPLY_A=-1.876, T_FILL_THIS_FORM_SHORT=0.01,
T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GTvngsvMxtNb for <scim@ietfa.amsl.com>;
Wed, 22 Jun 2022 15:50:08 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 64D44C164777
for <scim@ietf.org>; Wed, 22 Jun 2022 15:50:03 -0700 (PDT)
Received: from [192.168.1.153] (pool-108-26-202-2.bstnma.fios.verizon.net
[108.26.202.2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by chessie.everett.org (Postfix) with ESMTPSA id 4LSz9N2MBxzMNrs;
Wed, 22 Jun 2022 22:50:00 +0000 (UTC)
Content-Type: multipart/alternative;
boundary="------------4b9pasx2aDWiASh76hqrxTqv"
Message-ID: <d4e9bdf7-8530-ad12-cced-892a5fd59307@pdmconsulting.net>
Date: Wed, 22 Jun 2022 18:49:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Danny Zollner <Danny.Zollner@microsoft.com>, "scim@ietf.org"
<scim@ietf.org>
References: <MN2PR00MB0720A50B2E5EB355A07E5714FFAF9@MN2PR00MB0720.namprd00.prod.outlook.com>
<76b2c137-9ae4-74ab-0482-80328a7db032@pdmconsulting.net>
<MN2PR00MB0720CC2B7346ED47A504BC42FFB09@MN2PR00MB0720.namprd00.prod.outlook.com>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <MN2PR00MB0720CC2B7346ED47A504BC42FFB09@MN2PR00MB0720.namprd00.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/ko697ZstzUN2LYjLa2x7pOGml7E>
Subject: Re: [scim] [EXTERNAL] Re: Contributors needed for HR schema
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>,
<mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>,
<mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2022 22:50:15 -0000
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 <mayer@pdmconsulting.net> > *Sent:* Monday, June 20, 2022 1:34 PM > *To:* Danny Zollner <Danny.Zollner@microsoft.com>om>; 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 > > 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> >
- [scim] Contributors needed for HR schema Danny Zollner
- Re: [scim] Contributors needed for HR schema Danny Mayer
- Re: [scim] [EXTERNAL] Re: Contributors needed for… Danny Zollner
- Re: [scim] [EXTERNAL] Re: Contributors needed for… Danny Mayer