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

[Danny Mayer <[e-mail]>]

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 <[e-mail]> *On Behalf Of *Danny Mayer
> *Sent:* Sunday, November 14, 2021 17:07
> *To:* Phillip Hunt <[e-mail]>
> *Cc:* [e-mail]; Janelle Allen (janelall) 
> <janelall=[e-mail]>
> *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
>
> 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.
>
>     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
>
>     [e-mail]
>
>
>
>         On Nov 13, 2021, at 7:36 AM, Danny Mayer
>         <[e-mail]> wrote:
>
>         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
>
>         _______________________________________________
>         scim mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/scim
>         <https://www.ietf.org/mailman/listinfo/scim>
>
>
>
>     _______________________________________________
>
>     scim mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/scim
>
>
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim