Last Call Review of draft-ietf-scim-core-schema-17
review-ietf-scim-core-schema-17-secdir-lc-weis-2015-05-07-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

For the security area directions, I consider this document to be "Ready with
nits”.

This document documents resources a JSON scheme for Cross-Domain Identity
Management, a standard definition of attributes representing users and groups,
and a set of named schemas incorporating these attributes. The goal of the
document  is to make identity management in cloud based applications and
services easier. This is used when identity information needs to be shared
between services.

The Security Considerations (Section 9) in version 18 is reasonably clear in
the first two sub-sections that there are risks to sensitive information
defined in the schema, these sub-sections point to helpful text in
draft-ietf-scim. It is much improved over version 17. I have a couple of
comments suggesting clarification be added to the document.

Section 9.3 begins by stating the schema “defines attributes that MAY contain
personally identifiable information as well as other sensitive data”. I don’t
understand the “MAY”. Just about every attribute described in this document is
arguably personally identifiable information (PII), since transporting PII
between services seems to be the actual need for development of the schema. It
seems more accurate to say “defines attributes that contain personally
identifiable information as well as other sensitive data”. (Also “MAY” is
intended to declare a part of the standard that is optional for an
implementation, and I don’t see how that could apply here.)

Section 4.1.1 defines the “password” attribute as a “clear text password”. It
is much safer to store and pass a salted and hashed password. Do none of the
services using this schema support a method of hashing a user password to see
if it matches a given hashed value ? Or could this be an option in the scheme
definition? If so, it would be worth describing that here and in the Security
Considerations section.

 Brian