Subject: [scim] PII

From: Danny Mayer <[email-masked]>
Date: Mon, 3 Jan 2022 12:34:54 -0500

I'd like to restart this discussion. This comes under a number of headings:

1) Law and Regulations and Corporate Confidentiality Policies

2) Types of Organizations, Companies, etc.

3) Types of Data

4) Systems of Record for the data

There are probably other areas but let's start with this.

1) The legal side: GDPR in Europe, HIPAA in the US, and there are 
multiple other countries with restrictions on personal information and 
privacy. In addition companies have their own confidentiality 
requirements which may well exceed these laws and regulations.

2) Corporations have employees and they collect personal information 
about them so that they can be paid, the government can get taxes from 
them, etc. Financial Institutions need information on their customers so 
that they can verify information about them, report transactions to the 
government, etc. Stores, online and offline, store information about 
their customers, including name and address, credit/debit card 
information and transaction information. Social Media companies store 
data about their subscribers, principally to sell targeted 
advertisements to them but they store a lot of information about them.

3) Types of data stored are things like: Home addresses, Phone numbers, 
email addresses, National ID info, etc.

4) Systems of Records: HR stores information about employees, including 
home addresses, phone numbers, spouses and partners, children, National 
ID, pay information, title, manager, department, etc. A payroll system 
stores some of this information in order to pay the employees. An 
expense system may need some of this information.

Financial institutions store information about their customers for 
ensuring security of the customer accounts and to mail transaction 
information and statements to them and for government reporting 
requirements. They may need to share some of this information with other 
systems within the institution for various purposes.

Social Media companies have multiple application servers and they may 
share information between them.

So the questions for scim are as follows:

1) Do we restrict SCIM to only deal with HR systems and information or 
open it to the wider list?

2) Where and how do we identify which is PII and are there cases where 
sharing some of that information with other system is allowed (HR with 
Payroll for example).

3) What system is responsible for deciding what to share with which 
system? HR to Payroll for things like bank account information or home 
address. HR to Expenses for information like manager (who approves the 
expense). What information should an IDP have?

4) A number of HR systems that I've seen have API's which potentially 
allow you to download any information in the HR system. There are 
permissions that need to be set to allow that to happen for a given set 
of credentials but should SCIM require it to identify what is allowed 
and what is not valid and should it be different for different 
credentials? Who or what is the gatekeeper?

I hope this gets the discussion restarted.

Danny

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Mon, 3 Jan 2022 21:14:50 +0000

This topic seems like an authorization topic.  The HR system (or any datastore containing PII) exposing a SCIM service can show/hide PII based on its own already existing authorization model.   

Right?

--
Matt

-----Original Message-----
From: scim <[email-masked]> On Behalf Of Danny Mayer
Sent: Monday, January 3, 2022 10:35 AM
To: SCIM WG <[email-masked]>
Subject: [scim] PII

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

3) Types of Data

1) The legal side: GDPR in Europe, HIPAA in the US, and there are multiple other countries with restrictions on personal information and privacy. In addition companies have their own confidentiality requirements which may well exceed these laws and regulations.

2) Corporations have employees and they collect personal information about them so that they can be paid, the government can get taxes from them, etc. Financial Institutions need information on their customers so that they can verify information about them, report transactions to the government, etc. Stores, online and offline, store information about their customers, including name and address, credit/debit card information and transaction information. Social Media companies store data about their subscribers, principally to sell targeted advertisements to them but they store a lot of information about them.

3) Types of data stored are things like: Home addresses, Phone numbers, email addresses, National ID info, etc.

4) Systems of Records: HR stores information about employees, including home addresses, phone numbers, spouses and partners, children, National ID, pay information, title, manager, department, etc. A payroll system stores some of this information in order to pay the employees. An expense system may need some of this information.

Financial institutions store information about their customers for ensuring security of the customer accounts and to mail transaction information and statements to them and for government reporting requirements. They may need to share some of this information with other systems within the institution for various purposes.

Social Media companies have multiple application servers and they may share information between them.

1) Do we restrict SCIM to only deal with HR systems and information or open it to the wider list?

2) Where and how do we identify which is PII and are there cases where sharing some of that information with other system is allowed (HR with Payroll for example).

3) What system is responsible for deciding what to share with which system? HR to Payroll for things like bank account information or home address. HR to Expenses for information like manager (who approves the expense). What information should an IDP have?

4) A number of HR systems that I've seen have API's which potentially allow you to download any information in the HR system. There are permissions that need to be set to allow that to happen for a given set of credentials but should SCIM require it to identify what is allowed and what is not valid and should it be different for different credentials? Who or what is the gatekeeper?

Danny

_______________________________________________
scim mailing list
[email-masked]
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&amp;data=04%7C01%7Cmatt.peterson%40quest.com%7C68deba64fd3b4547db4908d9cedf65dc%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637768281154613797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=bY2UDBv1hvrTF3pM6veaKDhkY3%2B2YMTuBTtTn%2Bg5TTA%3D&amp;reserved=0

---

From: Leif Johansson <[email-masked]>
Date: Tue, 4 Jan 2022 12:03:10 +0100

On 2022-01-03 18:34, Danny Mayer wrote:
> 1) The legal side: GDPR in Europe, HIPAA in the US, and there are multiple other countries with restrictions on personal information and privacy. In addition companies have their own confidentiality
> 2) Corporations have employees and they collect personal information about them so that they can be paid, the government can get taxes from them, etc. Financial Institutions need information on their
> customers so that they can verify information about them, report transactions to the government, etc. Stores, online and offline, store information about their customers, including name and address,
> credit/debit card information and transaction information. Social Media companies store data about their subscribers, principally to sell targeted advertisements to them but they store a lot of
> information about them.
> 
> 4) Systems of Records: HR stores information about employees, including home addresses, phone numbers, spouses and partners, children, National ID, pay information, title, manager, department, etc. A
> payroll system stores some of this information in order to pay the employees. An expense system may need some of this information.
> 
> Financial institutions store information about their customers for ensuring security of the customer accounts and to mail transaction information and statements to them and for government reporting
> requirements. They may need to share some of this information with other systems within the institution for various purposes.
> 

My 5c worth inline below

> 1) Do we restrict SCIM to only deal with HR systems and information or open it to the wider list?

I don't think this is meaningful in the context of an IETF WG - even if there was a way to make such
a restriction there would be no way to enforce it in an interoperable way.

>From a GDPR pov, there is no way to establish such a scheme. The term "PII" is not even meaningful
in the context of GDPR. All personal data is subject to GDPR and the applicability of the law is highly
contextual. There is no way to deal with this at a protocol layer by identifying certain data as "PII".

> 
> 3) What system is responsible for deciding what to share with which system? HR to Payroll for things like bank account information or home address. HR to Expenses for information like manager (who
> approves the expense). What information should an IDP have?

Again an authoriation question and as such out of scope (or should be) for this WG. This will be a
deployment issue.

> 
> 4) A number of HR systems that I've seen have API's which potentially allow you to download any information in the HR system. There are permissions that need to be set to allow that to happen for a
> given set of credentials but should SCIM require it to identify what is allowed and what is not valid and should it be different for different credentials? Who or what is the gatekeeper?
> 

Same authorization question.

	Cheers Leif

> https://www.ietf.org/mailman/listinfo/scim

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 4 Jan 2022 22:22:05 +1100

in general, SCIM should consider a way for a client to purge records, not
just delete them (e.g. GDPR conformance). Whether systems are subject to
GDPR (or similar) will depend on various things, but the API should be at
least clear for how you ask for purge, and how a system denies that
operation, or reports success

Many healthcare systems, where this kind of question is pervasive, have
special ways to flag staff records, and VIP records. Such records get
special authorization processes, and additional audit log review. I would
think that some systems using SCIM have similar problems. It's not so
obvious that this calls for explicit SCIM support - there's properties and
groups, and so the raw functionality is there. is there benefit in
standardising this in SCIM? (note: we haven't seen the benefit in FHIR)

In FHIR we've found it necessary to have a resource for 'permissions'
directly, where individuals get to make and record decisions that
authorization decisions are then based on. One could imagine similar
considerations in e.g. HR systems. I don't think quite the same concerns
apply, and systems are having challenges operationalising it, but this is
where the discussion lead us to

Finally, for FHIR, we profiled OAuth to agree about the common scopes that
clients and servers know about and honor when OAuthing into a server - I
think that this at least partly what this question is about

Grahame
FHIR Project Lead
FHIR = RESTful API for healthcare

On Tue, Jan 4, 2022 at 10:03 PM Leif Johansson <[email-masked]> wrote:

> them, etc. Financial Institutions need information on their
> > customers so that they can verify information about them, report
> transactions to the government, etc. Stores, online and offline, store
> information about their customers, including name and address,
> > credit/debit card information and transaction information. Social Media
> companies store data about their subscribers, principally to sell targeted
> home addresses, phone numbers, spouses and partners, children, National ID,
> pay information, title, manager, department, etc. A
> > payroll system stores some of this information in order to pay the
> employees. An expense system may need some of this information.
> >
> address. HR to Expenses for information like manager (who
> permissions that need to be set to allow that to happen for a
> > given set of credentials but should SCIM require it to identify what is
> allowed and what is not valid and should it be different for different

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065
Benson & Grieve:   Principles of Health Interoperability (Health
Information Technology Standards), 4th ed -
http://www.springer.com/978-3-030-56882-5

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 4 Jan 2022 08:14:38 -0800

+1 to Leif’s comments. 

Not denying the concerns or the need but I too am not sure what is actionable. 

Phil

> On Jan 4, 2022, at 3:03 AM, Leif Johansson <[email-masked]> wrote:
> 
> 
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 4 Jan 2022 17:52:24 +0100

> Not denying the concerns or the need but I too am not sure what is actionable. 

Thats right. All very important questions but not something the IETF can do anything about.

	Cheers Leif

---

From: Danny Mayer <[email-masked]>
Date: Wed, 5 Jan 2022 17:17:30 -0500

> Thats right. All very important questions but not something the IETF can do anything about.

I don't disagree with anything said about this. It was however brought 
up during one of the meetings and I wanted to get this clarified. I 
haven't heard from anyone who thought it should be in-scope for the WG 
so unless we hear otherwise it looks like this will become consensus 
that it's out of scope. There was also a mention of an HR Schema but I 
don't think that makes a lot of sense unless whoever brought it up can 
clarify why it's needed.

Danny

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 5 Jan 2022 14:34:54 -0800

Danny

I am guessing but it seemed like it was just a request for a new schema to define attributes of interest to HR organizations. This can be done through the schema registration process listed in RFC7643 Section 10.3 using IANA.  It doesn’t seem like the general SCIM WG would have the expertise on what HR attributes to standardize. That said, the during process of registration, we may be called upon to comment (issues like name conflicts or other concerns).

Phillip Hunt
@independentid
[email-masked]

> On Jan 5, 2022, at 2:17 PM, Danny Mayer <[email-masked]> wrote:
> 
> 
> I don't disagree with anything said about this. It was however brought up during one of the meetings and I wanted to get this clarified. I haven't heard from anyone who thought it should be in-scope for the WG so unless we hear otherwise it looks like this will become consensus that it's out of scope. There was also a mention of an HR Schema but I don't think that makes a lot of sense unless whoever brought it up can clarify why it's needed.
> 
> Danny
>

---

From: Danny Zollner <[email-masked]>
Date: Wed, 5 Jan 2022 23:07:58 +0000

What I recall leading to this being included on the charter was a discussion in the informal SCIM Interest Group calls earlier this year that HR platforms are frequently the originating source for identity data, and integrations between HR platforms and consumers of their data (other apps, IdPs..) are tricky as the SCIM 2.0 core/enterprise schema doesn’t align closely enough with schemas from most HR providers. This is considered a possible reason for lack of adoption of SCIM by HR platforms.

I believe the goal was to get representatives from HR platforms involved with the SCIM WG to help craft a common HR-oriented SCIM schema so that integrations between HR platforms and others can be built more easily.

(I’m not particularly invested in this, so if any part of my recollection of how this came to be is wrong, someone please correct me)

-Danny Zollner

From: scim <[email-masked]> On Behalf Of Phillip Hunt
Sent: Wednesday, January 5, 2022 4:35 PM
To: Danny Mayer <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [scim] PII

Danny

Phillip Hunt
@independentid
[email-masked]<mailto:[email-masked]>

On Jan 5, 2022, at 2:17 PM, Danny Mayer <[email-masked]<mailto:[email-masked]>> wrote:

+1 to Leif’s comments.

Phil

               Cheers Leif

Danny

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Thu, 6 Jan 2022 01:27:30 +0000

I have same recollection as Danny - that the working group would be helpful in attracting representatives from HR platforms so that a consensus on an interoperable schema for HR data could be registered with IANA.  Without workgroup sponsorship, I'd be worried that we'd just see multiple (per-vendor) schema registrations which would defeat interoperability.

It's important to note that schema for HR data could be registered with IANA without specifying the authorization model and still be very useful for interoperability.  In other words, I'd support workgroup goal for HR schema, but leave authorization out of scope.

From: scim <[email-masked]> On Behalf Of Danny Zollner
Sent: Wednesday, January 5, 2022 4:08 PM
To: Phillip Hunt <[email-masked]>; Danny Mayer <[email-masked]>
Cc: [email-masked]
Subject: Re: [scim] [EXTERNAL] Re: PII

What I recall leading to this being included on the charter was a discussion in the informal SCIM Interest Group calls earlier this year that HR platforms are frequently the originating source for identity data, and integrations between HR platforms and consumers of their data (other apps, IdPs..) are tricky as the SCIM 2.0 core/enterprise schema doesn't align closely enough with schemas from most HR providers. This is considered a possible reason for lack of adoption of SCIM by HR platforms.

(I'm not particularly invested in this, so if any part of my recollection of how this came to be is wrong, someone please correct me)

-Danny Zollner

From: scim <[email-masked]<mailto:[email-masked]>> On Behalf Of Phillip Hunt
Sent: Wednesday, January 5, 2022 4:35 PM
To: Danny Mayer <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [scim] PII

Danny

I am guessing but it seemed like it was just a request for a new schema to define attributes of interest to HR organizations. This can be done through the schema registration process listed in RFC7643 Section 10.3 using IANA.  It doesn't seem like the general SCIM WG would have the expertise on what HR attributes to standardize. That said, the during process of registration, we may be called upon to comment (issues like name conflicts or other concerns).

Phillip Hunt
@independentid

+1 to Leif's comments.

Phil

               Cheers Leif

Danny

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7Cmatt.peterson%40quest.com%7C7ed1a3b23be1404bd14b08d9d0a0408f%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637770208984075874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=73G4zBGGHB3s7XOVL%2FQ2kDo7GD7v4YefIZMyIzG5aFU%3D&reserved=0>

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 5 Jan 2022 18:03:25 -0800

As I understand it, IANA will accept registration requests from any individual or organization. 

The IANA process is that there are designated experts (for the scim schema registry) that review the application. This is documented in 7643 and IANA. 

The intent of expert review is to address issues like name conflict or duplication. 

Phil

> On Jan 5, 2022, at 5:27 PM, Matt Peterson (mpeterso) <[email-masked]> wrote:
> 
> 
> I have same recollection as Danny – that the working group would be helpful in attracting representatives from HR platforms so that a consensus on an interoperable schema for HR data could be registered with IANA.  Without workgroup sponsorship, I’d be worried that we’d just see multiple (per-vendor) schema registrations which would defeat interoperability.
>  
> It’s important to note that schema for HR data could be registered with IANA without specifying the authorization model and still be very useful for interoperability.  In other words, I’d support workgroup goal for HR schema, but leave authorization out of scope.
>  
>