Subject: [scim] Discussion Item: Personally Identifiable Information in SCIM

From: "Janelle Allen (janelall)" <[email-masked]>
Date: Thu, 11 Nov 2021 15:13:40 +0000

Hi there,

In the IETF session today, Phil mentioned privacy and the handling of PII.  A lot of legislation has occurred since SCIM 2.0. A question to this WG, should we be revisiting the core schema and marking some attributes as potentially containing PII?

This caused me to ponder should we be thinking of modifying the core schema to identify which attributes may carry PII eg: the complex name attribute has the potential to carry PII,  should we consider adding a new item as a peer to “mutability” such as “containsPII: true/false”?. Or expand on the returned element such as returned: “restrictedPII”? or any other unmentioned method of addressing PII?

Thank you,
Janelle

---

From: Danny Mayer <[email-masked]>
Date: Sat, 13 Nov 2021 10:36:32 -0500

On 11/11/21 10:13 AM, Janelle Allen (janelall) wrote:

> Hi there,
>
> In the IETF session today, Phil mentioned privacy and the handling of 
> PII.  A lot of legislation has occurred since SCIM 2.0. A question to 
> this WG, should we be revisiting the core schema and marking some 
> attributes as potentially containing PII?
>
> This caused me to ponder should we be thinking of modifying the core 
> schema to identify which attributes may carry PII eg: the complex name 
> attribute has the potential to carry PII, should we consider adding a 
> new item as a peer to “mutability” such as “containsPII: true/false”?. 
> Or expand on the returned element such as returned: “restrictedPII”? 
> or any other unmentioned method of addressing PII?
>
I'd like to understand the use case for even providing PII data in SCIM. 
Most of the data that the SCIM Schemas currently are offering (see 
RFC7643) are not PII (though maybe ims and photos might be considered 
PII - Section 4.1.2). Having dealt with HR systems and their API's I 
know that there is only an extremely limited subset of data that should 
ever be made available to any outside system and you don't generally 
want to host it on a management platform if it is PII. I didn't attend 
the meeting so I don't know what the discussion was about. I personally 
feel that PII should NOT be made available through SCIM, but I'm willing 
to be persuaded otherwise as long as PII protections can be defined and 
required in any resulting document.

Danny

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 13 Nov 2021 11:41:51 -0800

Just for the group's information, the current SCIM specs do have privacy considerations sections. The confusion may be that back then, privacy considerations was not a top level table of contents items.

Relevant sections in existing drafts are:
RFC7644 Section 7.5 - https://datatracker.ietf.org/doc/html/rfc7644#section-7.5
RFC7643 Section 9 - https://datatracker.ietf.org/doc/html/rfc7643#section-9. This covers both sensitive data (e.g. passwords) as well as discussion on privacy.

Section RFC7644 7.5.2 refers to the case I pointed out in the WG session.  The HTTP POST .search method was designed to avoid passing information in request URIs that may appear in other 
systems such as access logs which may be seen as inappropriate.

A compliant service provider implementation that allows searching of PII and sensitive data via GET should normally be returning HTTP status 403 (Forbidden) in response.  While one might argue that information has already been exposed by the client, it doesn’t help to compound the problem by confirming that the infromation requested is correct.

The SCIM POST Search solution I raised was the result of a “compromise” the SCIM WG had to make for PII. The SCIM WG informally raised the concerns with the HTTP WG.
The HTTPbis WG has discussed the problems of searching with HTTP GET many times before. 

Julian Reschke presented on the issue in IETF93 (giving a good explanation of the privacy issues):
https://httpwg.org/wg-materials/ietf93/ietf-93-httpbis-search.pdf

Going forwards….

The issue of searching using HTTP GET has re-surfaced again with a proposal for HTTP QUERY:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/

If we end up talking about a SCIMbis effort, we may want to include support for safe query.  This would be fairly straight forward as we can take the body define in our POST search method and simply use the proposed HTTP QUERY method.

Phillip Hunt
@independentid
[email-masked]

> On Nov 13, 2021, at 7:36 AM, Danny Mayer <[email-masked]> wrote:
> 
> I'd like to understand the use case for even providing PII data in SCIM. Most of the data that the SCIM Schemas currently are offering (see RFC7643) are not PII (though maybe ims and photos might be considered PII - Section 4.1.2). Having dealt with HR systems and their API's I know that there is only an extremely limited subset of data that should ever be made available to any outside system and you don't generally want to host it on a management platform if it is PII. I didn't attend the meeting so I don't know what the discussion was about. I personally feel that PII should NOT be made available through SCIM, but I'm willing to be persuaded otherwise as long as PII protections can be defined and required in any resulting document.
> 
> Danny
> 
> _______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 14 Nov 2021 12:06:33 -0500

None of this answers my basic question of why PII would be a part of 
SCIM. HR systems (with the exception of a few properties) and Finance 
systems should not be sharing PII with other systems and a management 
system (a SCIM client) should not be aware of that information. I can 
imagine that an expense system, for example, might need some additional 
information from an HR system (like a physical address) but is that what 
is needed? The other need might be a payroll system needing Bank 
information for direct deposit and physical address, but you want that 
system to act as a direct SCIM client to HR and not go through any other 
servers for that information.

Does this make sense? Can someone come up with actual use cases to 
justify PII in SCIM?

Thanks,

Danny

On 11/13/21 2:41 PM, Phillip Hunt wrote:
>
> Just for the group's information, the current SCIM specs do have 
> privacy considerations sections. The confusion may be that back then, 
> privacy considerations was not a top level table of contents items.
>
> RFC7644 Section 7.5 - 
> https://datatracker.ietf.org/doc/html/rfc7644#section-7.5
> RFC7643 Section 9 - 
> https://datatracker.ietf.org/doc/html/rfc7643#section-9. This covers 
> both sensitive data (e.g. passwords) as well as discussion on privacy.
>
> Section RFC7644 7.5.2 refers to the case I pointed out in the WG 
> session.  The HTTP POST .search method was designed to avoid passing 
> information in request URIs that may appear in other
> A compliant service provider implementation that allows searching of 
> PII and sensitive data via GET should normally be returning HTTP 
> status 403 (Forbidden) in response.  While one might argue that 
> information has already been exposed by the client, it doesn’t help to 
> compound the problem by confirming that the infromation requested is 
> correct.
>
> The SCIM POST Search solution I raised was the result of a 
> “compromise” the SCIM WG had to make for PII. The SCIM WG informally 
> raised the concerns with the HTTP WG.
> If we end up talking about a SCIMbis effort, we may want to include 
> support for safe query.  This would be fairly straight forward as we 
> can take the body define in our POST search method and simply use the 
> proposed HTTP QUERY method.
>
> Phillip Hunt
> @independentid
>>> In the IETF session today, Phil mentioned privacy and the handling 
>>> of PII.  A lot of legislation has occurred since SCIM 2.0. A 
>>> question to this WG, should we be revisiting the core schema and 
>>> marking some attributes as potentially containing PII?
>>>
>>> schema to identify which attributes may carry PII eg: the complex 
>>> name attribute has the potential to carry PII,  should we consider 
>>> adding a new item as a peer to “mutability” such as “containsPII: 
>>> true/false”?. Or expand on the returned element such as returned: 
>>> “restrictedPII”? or any other unmentioned method of addressing PII?
>>
>> I'd like to understand the use case for even providing PII data in 
>> SCIM. Most of the data that the SCIM Schemas currently are offering 
>> (see RFC7643) are not PII (though maybe ims and photos might be 
>> considered PII - Section 4.1.2). Having dealt with HR systems and 
>> their API's I know that there is only an extremely limited subset of 
>> data that should ever be made available to any outside system and you 
>> don't generally want to host it on a management platform if it is 
>> PII. I didn't attend the meeting so I don't know what the discussion 
>> was about. I personally feel that PII should NOT be made available 
>> through SCIM, but I'm willing to be persuaded otherwise as long as 
>> PII protections can be defined and required in any resulting document.
>>
>> Danny
>>
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: "Paulo Jorge N. Correia (paucorre)" <[email-masked]>
Date: Mon, 15 Nov 2021 10:24:31 +0000

Danny,

Email address, phone numbers, locations, most of it is consider PII, and the what is even more problematic is when that information travels across clouds.

Many regulations like European GDPR (https://gdpr.eu/eu-gdpr-personal-data/), but not only EU, most of the geos like Canada, Singapore, etc. are creating similar legislations are controlling and monitoring what you do with PII

So I would say that is very very relevant that SCIM have the right mechanisms for the GEOs regulation can by enforce or not.

Of course this will require that some kind of privacy expert (normally Lawyer) to have a look at the RFC schemas and do recommendation if each attribute is consider PII or not.

Thanks,

Paulo

From: scim <[email-masked]> On Behalf Of Danny Mayer
Sent: Sunday, November 14, 2021 17:07
To: Phillip Hunt <[email-masked]>
Cc: [email-masked]; Janelle Allen (janelall) <janelall=[email-masked]>
Subject: Re: [scim] Discussion Item: Personally Identifiable Information in SCIM

None of this answers my basic question of why PII would be a part of SCIM. HR systems (with the exception of a few properties) and Finance systems should not be sharing PII with other systems and a management system (a SCIM client) should not be aware of that information. I can imagine that an expense system, for example, might need some additional information from an HR system (like a physical address) but is that what is needed? The other need might be a payroll system needing Bank information for direct deposit and physical address, but you want that system to act as a direct SCIM client to HR and not go through any other servers for that information.

Does this make sense? Can someone come up with actual use cases to justify PII in SCIM?

Thanks,

Danny

Going forwards….

Phillip Hunt

@independentid

[email-masked] <mailto:[email-masked]> 

On Nov 13, 2021, at 7:36 AM, Danny Mayer <[email-masked] <mailto:[email-masked]> > wrote:

Hi there,

Danny

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

---

From: Danny Mayer <[email-masked]>
Date: Mon, 15 Nov 2021 18:53:58 -0500

Paulo,

Are those Personal information or Corporate information? If they are 
personal email addresses, for example, then I would agree, but what 
about your business email address? The URL you referenced did not 
differentiate between the two. Most corporate systems only want the 
business email address and only HR will have a personal email address. 
If need be we can specify that a personal email address not be part of 
the SCIM schema while a business email address can. If we can understand 
what GDPR requires for PII for email addresses the rest of what you 
referenced will likely be the same. We can have a further discussion 
after that on the security requirements for any PII. Note that GDPR is 
not the only requirement for PII. California in the US also has 
requirements and I know that other non-EU countries also have requirements.

Danny

On 11/15/21 5:24 AM, Paulo Jorge N. Correia (paucorre) wrote:
>
> Danny,
>
> Email address, phone numbers, locations, most of it is consider PII, 
> and the what is even more problematic is when that information travels 
> across clouds.
>
> Many regulations like European GDPR 
> (https://gdpr.eu/eu-gdpr-personal-data/), but not only EU, most of the 
> geos like Canada, Singapore, etc. are creating similar legislations 
> are controlling and monitoring what you do with PII
>
> So I would say that is very very relevant that SCIM have the right 
> mechanisms for the GEOs regulation can by enforce or not.
>
> Of course this will require that some kind of privacy expert (normally 
> Lawyer) to have a look at the RFC schemas and do recommendation if 
> each attribute is consider PII or not.
>
> Thanks,
>
> Paulo
>
> *From:* scim <[email-masked]> *On Behalf Of *Danny Mayer
> *Sent:* Sunday, November 14, 2021 17:07
> *To:* Phillip Hunt <[email-masked]>
> *Cc:* [email-masked]; Janelle Allen (janelall) 
> <janelall=[email-masked]>
> *Subject:* Re: [scim] Discussion Item: Personally Identifiable 
> Information in SCIM
>
> imagine that an expense system, for example, might need some 
> additional information from an HR system (like a physical address) but 
> is that what is needed? The other need might be a payroll system 
> needing Bank information for direct deposit and physical address, but 
> you want that system to act as a direct SCIM client to HR and not go 
> through any other servers for that information.
>
>     privacy considerations sections. The confusion may be that back
>     then, privacy considerations was not a top level table of contents
>     items.
>
>     https://datatracker.ietf.org/doc/html/rfc7643#section-9. This
>     covers both sensitive data (e.g. passwords) as well as discussion
>     on privacy.
>
>     session.  The HTTP POST .search method was designed to avoid
>     passing information in request URIs that may appear in other
>
>     A compliant service provider implementation that allows searching
>     of PII and sensitive data via GET should normally be returning
>     HTTP status 403 (Forbidden) in response.  While one might argue
>     that information has already been exposed by the client, it
>     doesn’t help to compound the problem by confirming that the
>     infromation requested is correct.
>
>     “compromise” the SCIM WG had to make for PII. The SCIM WG
>     informally raised the concerns with the HTTP WG.
>
>     If we end up talking about a SCIMbis effort, we may want to
>     include support for safe query.  This would be fairly straight
>     forward as we can take the body define in our POST search method
>     and simply use the proposed HTTP QUERY method.
>
>     Phillip Hunt
>
>     @independentid
>
>             In the IETF session today, Phil mentioned privacy and the
>             handling of PII. A lot of legislation has occurred since
>             SCIM 2.0. A question to this WG, should we be revisiting
>             the core schema and marking some attributes as potentially
>             containing PII?
>
>             This caused me to ponder should we be thinking of
>             modifying the core schema to identify which attributes may
>             carry PII eg: the complex name attribute has the potential
>             to carry PII, should we consider adding a new item as a
>             peer to “mutability” such as “containsPII: true/false”?.
>             Or expand on the returned element such as returned:
>         I'd like to understand the use case for even providing PII
>         data in SCIM. Most of the data that the SCIM Schemas currently
>         are offering (see RFC7643) are not PII (though maybe ims and
>         photos might be considered PII - Section 4.1.2). Having dealt
>         with HR systems and their API's I know that there is only an
>         extremely limited subset of data that should ever be made
>         available to any outside system and you don't generally want
>         to host it on a management platform if it is PII. I didn't
>         attend the meeting so I don't know what the discussion was
>         about. I personally feel that PII should NOT be made available
>         through SCIM, but I'm willing to be persuaded otherwise as
>         long as PII protections can be defined and required in any
>         resulting document.
>
>         Danny
>
>         <https://www.ietf.org/mailman/listinfo/scim>
>
>
>

---

From: Radovan Semancik <[email-masked]>
Date: Tue, 16 Nov 2021 08:36:11 +0100

Hello,

The situation is much more complicated that it may seem.

First of all, this issue is not limited to personally-identifiable 
information (PII), it also applied to personal data (please see our 
glossary [1] for clarification). In fact, GDPR and similar regulations 
deal with personal data, not just PII. Therefore it is better to 
consider personal data instead of PII.

Secondly, it is not very practical to deal with notion of personal data 
in the schema, especially in a system with considerably static schema 
definition such as SCIM. Whether a particular information is considered 
personal data heavily depends on context. E-mail address may be 
considered personal data (even if it is "corporate"), however if it is 
alias, distribution list or e-mail address used by automated processing 
system it probably won't be personal data, as there is no person behind 
it. Therefore the schema can specify that a particular data item may 
potentially contain personal data. But that is true for almost any data 
item, as the user may enter his SSN into a description. Obviously, 
having a probability of particular item containing a personal data is 
not very helpful either. Marking personal data in the schema not a way 
to go. Maybe marking it in metadata for every value? Well, that is quite 
complicated (e.g. see our data provenance project [2]), and it is even 
more complicated that it seems, because the other thing below.

Thirdly, knowing that some piece of data is "personal data" does not 
gives much information regarding its use - and it is use of personal 
data that matters. Storage and transfer of personal data is important, 
but ultimately it is the use of that that will get you in trouble. How 
should the client behave if something is marked as "personal data"? 
Should consent be requested from user? Or was the consent already given? 
For what purpose was the consent given? Oh, pardon my French, "consent" 
is really a dirty word ... so, is there any legal basis for use of the 
data? What legal basis? What are the constraints for data use? How to 
deal with data erasure? Those are the questions that matter, and they 
cannot be answered by simple "PII flag" in the schema.

This problem is not fully understood, not even by the identity 
management professionals. The technology is not mature enough, e.g. 
there is obviously a need for a rich value metadata, however, this is 
not really supported (or even envisioned) by schema languages (including 
SCIM schema). We are aware of this problem for many years, and last year 
we have tried to prototype a solution (see [2]). The prototype was quite 
successful, but it also uncovered hidden complexity ([3]).

SCIM is so not prepared for any of this. Even if a series of 
precisely-timed miracles happen and this can be somehow handled in SCIM 
specs, vast majority of SCIM clients will not be prepared for this 
anyway. And those that are won't agree on data protection metadata 
schema. This is a very unstable area for experiments and prototypes. It 
is way too early for standardization.

[1]
https://docs.evolveum.com/glossary/#personally-identifiable-information
https://docs.evolveum.com/glossary/#personal-data

[2]
https://docs.evolveum.com/midpoint/projects/midprivacy/phases/01-data-provenance-prototype/

[3]
https://docs.evolveum.com/midpoint/projects/midprivacy/phases/01-data-provenance-prototype/provenance-origin-basis/

-- 
Radovan Semancik
Software Architect
evolveum.com

On 16. 11. 2021 0:53, Danny Mayer wrote:
> the SCIM schema while a business email address can. If we can 
> understand what GDPR requires for PII for email addresses the rest of 
> what you referenced will likely be the same. We can have a further 
> discussion after that on the security requirements for any PII. Note 
> that GDPR is not the only requirement for PII. California in the US 
> also has requirements and I know that other non-EU countries also have 
> requirements.
>
> Danny
>
>> and the what is even more problematic is when that information 
>> travels across clouds.
>>
>> (https://gdpr.eu/eu-gdpr-personal-data/), but not only EU, most of 
>> the geos like Canada, Singapore, etc. are creating similar 
>> legislations are controlling and monitoring what you do with PII
>>
>> Of course this will require that some kind of privacy expert 
>> (normally Lawyer) to have a look at the RFC schemas and do 
>> recommendation if each attribute is consider PII or not.
>>
>> Thanks,
>>
>> Paulo
>>
>> additional information from an HR system (like a physical address) 
>> but is that what is needed? The other need might be a payroll system 
>>     then, privacy considerations was not a top level table of
>>     contents items.
>>
>>             the core schema and marking some attributes as
>>             potentially containing PII?
>>
>>             modifying the core schema to identify which attributes
>>             may carry PII eg: the complex name attribute has the
>>             potential to carry PII, should we consider adding a new
>>             item as a peer to “mutability” such as “containsPII:
>>             true/false”?. Or expand on the returned element such as
>>             returned: “restrictedPII”? or any other unmentioned
>>             method of addressing PII?
>>
>>         data in SCIM. Most of the data that the SCIM Schemas
>>         currently are offering (see RFC7643) are not PII (though
>>         maybe ims and photos might be considered PII - Section
>>         4.1.2). Having dealt with HR systems and their API's I know
>>         that there is only an extremely limited subset of data that
>>         should ever be made available to any outside system and you
>>         don't generally want to host it on a management platform if
>>         it is PII. I didn't attend the meeting so I don't know what
>>         the discussion was about. I personally feel that PII should
>>         NOT be made available through SCIM, but I'm willing to be
>>         persuaded otherwise as long as PII protections can be defined
>>         and required in any resulting document.
>>
>>         Danny
>>

---

From: "Janelle Allen (janelall)" <[email-masked]>
Date: Tue, 16 Nov 2021 17:34:02 +0000

Thank you for providing your thoughts based on your valuable experience.

From: scim <[email-masked]> on behalf of Radovan Semancik <radovan.semancik=[email-masked]>
Date: Tuesday, November 16, 2021 at 12:36 AM
To: [email-masked] <[email-masked]>
Subject: Re: [scim] Discussion Item: Personally Identifiable Information in SCIM

Hello,

First of all, this issue is not limited to personally-identifiable information (PII), it also applied to personal data (please see our glossary [1] for clarification). In fact, GDPR and similar regulations deal with personal data, not just PII. Therefore it is better to consider personal data instead of PII.

Secondly, it is not very practical to deal with notion of personal data in the schema, especially in a system with considerably static schema definition such as SCIM. Whether a particular information is considered personal data heavily depends on context. E-mail address may be considered personal data (even if it is "corporate"), however if it is alias, distribution list or e-mail address used by automated processing system it probably won't be personal data, as there is no person behind it. Therefore the schema can specify that a particular data item may potentially contain personal data. But that is true for almost any data item, as the user may enter his SSN into a description. Obviously, having a probability of particular item containing a personal data is not very helpful either. Marking personal data in the schema not a way to go. Maybe marking it in metadata for every value? Well, that is quite complicated (e.g. see our data provenance project [2]), and it is even more complicated that it seems, because the other thing below.

Thirdly, knowing that some piece of data is "personal data" does not gives much information regarding its use - and it is use of personal data that matters. Storage and transfer of personal data is important, but ultimately it is the use of that that will get you in trouble. How should the client behave if something is marked as "personal data"? Should consent be requested from user? Or was the consent already given? For what purpose was the consent given? Oh, pardon my French, "consent" is really a dirty word ... so, is there any legal basis for use of the data? What legal basis? What are the constraints for data use? How to deal with data erasure? Those are the questions that matter, and they cannot be answered by simple "PII flag" in the schema.

This problem is not fully understood, not even by the identity management professionals. The technology is not mature enough, e.g. there is obviously a need for a rich value metadata, however, this is not really supported (or even envisioned) by schema languages (including SCIM schema). We are aware of this problem for many years, and last year we have tried to prototype a solution (see [2]). The prototype was quite successful, but it also uncovered hidden complexity ([3]).

SCIM is so not prepared for any of this. Even if a series of precisely-timed miracles happen and this can be somehow handled in SCIM specs, vast majority of SCIM clients will not be prepared for this anyway. And those that are won't agree on data protection metadata schema. This is a very unstable area for experiments and prototypes. It is way too early for standardization.
[1]
https://docs.evolveum.com/glossary/#personally-identifiable-information
https://docs.evolveum.com/glossary/#personal-data

[2]

[3]

--

Radovan Semancik

Software Architect

evolveum.com

Paulo,

Are those Personal information or Corporate information? If they are personal email addresses, for example, then I would agree, but what about your business email address? The URL you referenced did not differentiate between the two. Most corporate systems only want the business email address and only HR will have a personal email address. If need be we can specify that a personal email address not be part of the SCIM schema while a business email address can. If we can understand what GDPR requires for PII for email addresses the rest of what you referenced will likely be the same. We can have a further discussion after that on the security requirements for any PII. Note that GDPR is not the only requirement for PII. California in the US also has requirements and I know that other non-EU countries also have requirements.

Danny

Thanks,
Paulo

From: scim <[email-masked]><mailto:[email-masked]> On Behalf Of Danny Mayer
Sent: Sunday, November 14, 2021 17:07
To: Phillip Hunt <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Janelle Allen (janelall) <janelall=[email-masked]><mailto:janelall=[email-masked]>
Subject: Re: [scim] Discussion Item: Personally Identifiable Information in SCIM

Thanks,

Danny

Going forwards….

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

On Nov 13, 2021, at 7:36 AM, Danny Mayer <[email-masked]<mailto:[email-masked]>> wrote:

I'd like to understand the use case for even providing PII data in SCIM. Most of the data that the SCIM Schemas currently are offering (see RFC7643) are not PII (though maybe ims and photos might be considered PII - Section 4.1.2). Having dealt with HR systems and their API's I know that there is only an extremely limited subset of data that should ever be made available to any outside system and you don't generally want to host it on a management platform if it is PII. I didn't attend the meeting so I don't know what the discussion was about. I personally feel that PII should NOT be made available through SCIM, but I'm willing to be persuaded otherwise as long as PII protections can be defined and required in any resulting document.
Danny
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

scim mailing list

[email-masked]<mailto:[email-masked]>

scim mailing list

[email-masked]<mailto:[email-masked]>

scim mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Matt Peterson (mpeterso)" <[email-masked]>
Date: Tue, 23 Nov 2021 20:27:08 +0000

Amen.

From: scim <[email-masked]> On Behalf Of Radovan Semancik
Sent: Tuesday, November 16, 2021 12:36 AM
To: [email-masked]
Subject: Re: [scim] Discussion Item: Personally Identifiable Information in SCIM

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.

Hello,

SCIM is so not prepared for any of this. Even if a series of precisely-timed miracles happen and this can be somehow handled in SCIM specs, vast majority of SCIM clients will not be prepared for this anyway. And those that are won't agree on data protection metadata schema. This is a very unstable area for experiments and prototypes. It is way too early for standardization.
[1]
https://docs.evolveum.com/glossary/#personally-identifiable-information<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.evolveum.com%2Fglossary%2F%23personally-identifiable-information&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946886065%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Xq%2Ftw3UsvEPnR03UAN5Z%2BkFBgA6MRGqtQCg9lRruSug%3D&reserved=0>
https://docs.evolveum.com/glossary/#personal-data<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.evolveum.com%2Fglossary%2F%23personal-data&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946896060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=e0e1LIIz%2BLWoJHa3Z7TrfpTVolFyQQIuxgO5J45A%2BaQ%3D&reserved=0>

[2]
https://docs.evolveum.com/midpoint/projects/midprivacy/phases/01-data-provenance-prototype/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.evolveum.com%2Fmidpoint%2Fprojects%2Fmidprivacy%2Fphases%2F01-data-provenance-prototype%2F&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946896060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ASYmPWISXt2xDNpACSUQw9wlFj3RyTfV7Yb%2BxJkIISY%3D&reserved=0>

[3]
https://docs.evolveum.com/midpoint/projects/midprivacy/phases/01-data-provenance-prototype/provenance-origin-basis/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.evolveum.com%2Fmidpoint%2Fprojects%2Fmidprivacy%2Fphases%2F01-data-provenance-prototype%2Fprovenance-origin-basis%2F&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946906058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MZ%2FxVsEX2bFs8Kn8w3G34VBCtEQI5VzaXC0Qip23XqY%3D&reserved=0>

--

Radovan Semancik

Software Architect

evolveum.com

Paulo,

Danny
On 11/15/21 5:24 AM, Paulo Jorge N. Correia (paucorre) wrote:
Danny,
Email address, phone numbers, locations, most of it is consider PII, and the what is even more problematic is when that information travels across clouds.
Many regulations like European GDPR (https://gdpr.eu/eu-gdpr-personal-data/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgdpr.eu%2Feu-gdpr-personal-data%2F&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946916052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eZxKCphpOOJohCtgNHc6H1oD6a22Y5ZdH%2FmPRLFiNe8%3D&reserved=0>), but not only EU, most of the geos like Canada, Singapore, etc. are creating similar legislations are controlling and monitoring what you do with PII

Thanks,
Paulo

Thanks,

Danny

Relevant sections in existing drafts are:
RFC7644 Section 7.5 - https://datatracker.ietf.org/doc/html/rfc7644#section-7.5<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-7.5&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946916052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mWV7uw4BVEHlMc5B%2FEg%2BHalg8tPWPPGS1xyB3TeCNiY%3D&reserved=0>
RFC7643 Section 9 - https://datatracker.ietf.org/doc/html/rfc7643#section-9<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7643%23section-9&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946926047%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tlvbTZ5LJZ3rtFuyK21P6ARsy6IZDKvsczcI7%2BI2UX4%3D&reserved=0>. This covers both sensitive data (e.g. passwords) as well as discussion on privacy.

A compliant service provider implementation that allows searching of PII and sensitive data via GET should normally be returning HTTP status 403 (Forbidden) in response.  While one might argue that information has already been exposed by the client, it doesn't help to compound the problem by confirming that the infromation requested is correct.

The SCIM POST Search solution I raised was the result of a "compromise" the SCIM WG had to make for PII. The SCIM WG informally raised the concerns with the HTTP WG.
The HTTPbis WG has discussed the problems of searching with HTTP GET many times before.

Julian Reschke presented on the issue in IETF93 (giving a good explanation of the privacy issues):
https://httpwg.org/wg-materials/ietf93/ietf-93-httpbis-search.pdf<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fwg-materials%2Fietf93%2Fietf-93-httpbis-search.pdf&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946936042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=czln72qj%2F5zGmTE%2FgvUThcKQTMUZDf3tH9rxYPbQBgM%3D&reserved=0>

Going forwards....

The issue of searching using HTTP GET has re-surfaced again with a proposal for HTTP QUERY:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-httpbis-safe-method-w-body%2F&data=04%7C01%7Cmatt.peterson%40quest.com%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946936042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KunzOuJuFNOh%2B7a9N55PYc%2F69TR6YsRJfwwZFxgqwnw%3D&reserved=0>

Phillip Hunt
@independentid

This caused me to ponder should we be thinking of modifying the core schema to identify which attributes may carry PII eg: the complex name attribute has the potential to carry PII,  should we consider adding a new item as a peer to "mutability" such as "containsPII: true/false"?. Or expand on the returned element such as returned: "restrictedPII"? or any other unmentioned method of addressing PII?

I'd like to understand the use case for even providing PII data in SCIM. Most of the data that the SCIM Schemas currently are offering (see RFC7643) are not PII (though maybe ims and photos might be considered PII - Section 4.1.2). Having dealt with HR systems and their API's I know that there is only an extremely limited subset of data that should ever be made available to any outside system and you don't generally want to host it on a management platform if it is PII. I didn't attend the meeting so I don't know what the discussion was about. I personally feel that PII should NOT be made available through SCIM, but I'm willing to be persuaded otherwise as long as PII protections can be defined and required in any resulting document.
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%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946946042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JL5k5PUhU9dV0eSkwsCDmd%2FlRLBcplTHoeaUa4hp%2FTI%3D&reserved=0>

scim mailing list

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%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946956041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W5QtWeGWt7PHv1fGJzy%2BdpyTJIAGT4NAvstOzpeKohU%3D&reserved=0>

scim mailing list

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%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946956041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W5QtWeGWt7PHv1fGJzy%2BdpyTJIAGT4NAvstOzpeKohU%3D&reserved=0>

scim mailing list

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%7Ccce2d0da621c4dec23b108d9a8d3ce4b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637726449946966035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6YR%2B08xbaHcS9Y4c9j5KcfS%2FDwfV4oAXgKbOP%2B4Ds7o%3D&reserved=0>