Subject: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-18: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 11 May 2015 07:32:08 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-scim-core-schema-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft.  I do have a few items to discuss,
but think they should be fairly easy to resolve.

1. Thanks for addressing the SecDir review and agreeing to put some text
in about the clear text passwords and the difference between a hashed
version.  I'll remove the discuss on this once the updated draft is
posted.
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html

2. I see the discussion from the SecDir review changes "MAY" to "may' in
section 9, but I'm wondering why the word may is used as many of the
attributes are PII.  How about:

	"defines attributes that are sensitive and the contents are considered
personally identifiable information(PII)"

I have some more questions on PII and a suggestion to help resolve the
concerns.

3. Is there a reason why the considerations are limited to/with an
emphasis on the id and externalId?  Most of the attributes defined in
section 4 are considered PII.  The id and externalID provide an index and
that's important to protect, but so are many of the (optional)
attributes.  It would be good to make this clear in the draft.  Since it
is pointed out on id, it seems like the other attributes don't have
privacy considerations when reading the draft, but a summary statement at
the start of the draft would help where the index "id" is distinguished
from the other sensitive attributes.

4. It would help to have a statement that lists the scope of where SCIM
is used and that the protocol design requires encryption when this data
is in transit (per the api draft), since most of the attributes defined
would contain PII when used.  

I'm making some assumptions, so please correct the text to the scope of
SCIM.  The abstract has the following sentence:
   "This schema is intended for exchange and use with cloud
   service providers."
What about the following:
   "This schema is intended for exchange and use with cloud
   service providers and their customers."

There is also this statement int he introduction:
   "This schema is intended for exchange and use with
   cloud service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, permission to provide
customers user information between service providers gets tricky and I
don't think that was covered in the API draft, but please let me know if
I missed it.

If data exchanged using the SCIM schema is just between an organization
and a contracted service provider, there should be SLAs for security and
that could be noted in the introduction with the scope statement.  This
will alleviate some of the privacy and security concerns as you can state
the concerns, but leave it up to implementers and contracts to handle the
details.  If the scope statement changes, something along the lines of
the following could help:
    "Security service level agreements for the handling of these
    attributes are outside the scope of this document, but are to
    be carefully considered by implementers."

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 May 2015 17:31:12 +0200

> https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

I would vote to keep the 'may' in there because of the legal
implications of the term "personally identifiable information"
esp in some jurisdictions - I would prefer to avoid making
statements that could be confused with legal advise :-)

> from the other sensitive attributes.

Here I actually agree. Maybe extend the original caveat on PII to almost
everything in scim?

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 11:13:43 -0700

Kathleen,

Thanks for your review. I’ve put quite a few comments below. 

I think we may have a different interpretation of the term “PII”. I do not believe that all SCIM information constitutes PII (personally identifiable information). My interpretation is that usually a PII “attribute” can, by itself, be used to identify an individual. A Social Security Number, an email address are all PII.  While eye color and address may not. While many people have “blue” eyes, that information alone does not point to an individual. Yet, it has been shown that a surprisingly limited combination of sensitive information can be used together to identify individuals. There is already significant research into the area of re-identification. This merely underlines the need for protection of sensitive information and not just PII.  My understanding is that the determination of PII largely depends on the legal jurisdiction and what requirements are set out. 

Would it be best to first define what is meant by PII and sensitive information?  In the spec, PII is a specific sub-set of personal information for which we are calling for specific concerns.

Phil

[email-masked]

> On May 11, 2015, at 7:32 AM, Kathleen Moriarty <[email-masked]> wrote:
> 

Thanks
> personally identifiable information(PII)”

(see above)

Let me know if this text (slightly different from draft 18 works:

  The SCIM Core schema defines attributes that are sensitive and may be
  considered personally identifying information (PII).  These privacy
  considerations should be considered for extensions as well as the
  schema defined in this specification.

> from the other sensitive attributes.

I’m not sure I understand. We called particular attention to “id” and “externalId” because their were protocol specific concerns. While the draft calls out particular concerns for “id” and “externalId”, the intent is not to diminish the concern for other sensitive attributes.

The second paragraph reads….
  Attributes such as "id" and "externalId" are of particular concern as
  personally identifiable information that uniquely map to Users
  (because they are URIs).  ...

> would contain PII when used.  

Again. I would draw a distinction between PII and Personally Sensitive Information.

We’re assuming all information is sensitive and is critical.

The initial driving case was enterprises purchasing services for their employees from cloud service providers need a standardized way to initialize those profiles.

Since then, we are hearing usage like mobile apps obtaining User profile information from service providers.  E.g. The mobile app downloads the user profile that was set up using the browser version of an application (e.g. conferencing system).

I am also hearing about cloud-to-cloud where a user (and/or their employer) would like to access services from another cloud provider or partner. The initial cloud provider sets up accounts on request on the users behalf.  Some of this may be done by corporate agreement, or through delegated authorizations such as issued by an OAuth authorization server as agreed to by the user.

We are also seeing broad interest in SCIM as a Profile service — essentially this generations HTTP Directory Service. The pairing of SCIM and OAuth gives new user control over their information and its propagation. (this is beyond the current charter)

There is also an emerging use of SCIM for managing identities for OAuth Clients and things.  In particular a lot of work is being done on IoT. What makes this interesting, is that some of this are just device identities, but they still carry risk from a network security perspective. We also then have the fact that many devices are also tightly associated with Users, either because they possess them or because they are delegating rights to the devices.

I’ve said all this, because I’m not sure we need to specify any of this. To specify a scope suggests we want to specifically limit use. I’m not sure that is appropriate.

>  service providers and their customers.”

The sentence was vague because the charter included both enterprise-to-cloud and cloud-to-cloud.
> don't think that was covered in the API draft, but please let me know if

We did not discuss permission systems. SCIM was chartered as a provisioning protocol. This might be appropriate if we want to discuss a SCIM Directory charter down the road.
>   be carefully considered by implementers.”

Agreed. I’m happy to put this in. Editorially, I am concerned about including too much material that doesn’t specify actions implementers should do.  

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 11:15:24 -0700

Please ignore this last message.  It appears to be an old draft message.

Phil

@independentid
www.independentid.com
[email-masked]

> On May 12, 2015, at 11:13 AM, Phil Hunt <[email-masked]> wrote:
> 
> Kathleen,
> 
> [email-masked] <mailto:[email-masked]>
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim