System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
draft-ietf-scim-use-cases-08

[Ballot discuss]
I had a discuss on section 3.4, that should be quick to clear up on privacy and security considerations. 

My concern is on the requirements in section 3.4 and maybe it's a language issue where I am reading this differently than it was intended.  If that's the case, it would be good to make sure the text and intent is clear.

Current text:
Requirements:

  o  YourHR must ensure that the personal information generated by the
      local offices is timely available in a globally-accessible
      database.

  o  Identity management of the personal data must be protected against
      unauthorised access and remain confidential to only authorised
      parties.

  o  All operation with identity data must be securely logged.

  o  The logs should be available for auditing.

My concern is with bullets 1 & 2.  To me, this reads as though personal information will be globally available and just the identity management information is protected.  What is meant by globally available and are there some access restrictions?

Sorry This was not in my review yesterday, I had a UI error.

[Ballot comment]
- From the charter:
  The use cases document will be a "living document", guiding the
  working group during its development of the standards.  The group may
  take snapshots of that document for Informational publication, to
  serve as documentation of the motivation for the work in progress
  and to similarly guide planning and implementation.

  ...
  Mar 2013 - Initial adoption of SCIM use cases, as a living document

Looking at the charter and the draft name, I was ready to ask: is this a living document? should it be published?
Reading the draft, it contains way more than the use cases: concepts and requirements are included.
Which means that, even if you add new use cases, the requirements will (hopefully) not change. This is a good reason to publish.
You should really update the title, and potentially the abstract to match the content: a mix of use cases, requirements, some (framework type of level) concepts and flows. Don't get me wrong, it's not a bad thing to combine all these into a single document, and I enjoyed the read.
Proposal: from "SCIM Definitions, Overview, and Flows" to something such as "SCIM Definitions, Overview, Concepts, and Requirements"

- I'm certainly not an expert in identity management, but I understood the difference between SCIM and ABFAB as ABFAB = just in time provisioning, as opposed to SCIM = pre-provisioning (ok, except maybe in the SSO "special" use case). A few words on this in the intro would have helped me to put the right context.

Editorial:
- It's intent is to reduce -> Its intend is to reduce
- C.R.U.D -> CRUD (since you have it in the acronym section)

[Ballot comment]
- From the charter:
  The use cases document will be a "living document", guiding the
  working group during its development of the standards.  The group may
  take snapshots of that document for Informational publication, to
  serve as documentation of the motivation for the work in progress
  and to similarly guide planning and implementation.

  ...
  Mar 2013 - Initial adoption of SCIM use cases, as a living document

Looking at the charter and the draft name, I was ready to ask: is this a living document? should it be published?
Reading the draft, it contains way more than the use cases: concepts and requirements are included.
Which means that, even if you add new use cases, the requirements will (hopefully) not change. This is a good reason to publish.
You should really update the title, and potentially the abstract to match the content: a mix of use cases, requirements, some (framework type of level) concepts and flows. Don't get me wrong, it's not a bad thing to combine all these into a single document, and I enjoyed the read.
Proposal: from "SCIM Definitions, Overview, and Flows" to something such as "SCIM Definitions, Overview, Concepts, and Requirements"

- I'm certainly an expert in identity management, so maybe it's obvious to everybody. I understood the difference between SCIM and ABFAB as ABFAB = just in time provisioning, as opposed to SCIM = pre-provisioning (ok, except maybe in the SSO "special" use case). A few words on this in the intro would have helped me

Editorial:
- It's intent is to reduce -> Its intend is to reduce
- C.R.U.D -> CRUD (since you have it in the acronym section)

[Ballot comment]
Section 2.4
I agree with Stephen's question on the assumption of using LDAP.  If its' just an example, could you say that or abstract it from LDAP or a particular choice.

Section 3.2
I agree with Stephen (his comment on security considerations section) that there should be some mention of regulatory concerns when moving identity information between jurisdictional regions (countries, state-by-state for regulations on privacy, and universities have additional regulations on personal information).  This also applies to Section 3.4 (or likely all use cases) as personal information is discussed in that use case description.  For section 3.4, you'd need to worry about where accounts are provisioned.

Nit:
Section 2.3.4
  At the protocol level, this class of scenarios may result in the use
  of common protocol exchange patters between CSP-1 & CSP-2.
s/patters/patterns/

[Ballot comment]

- 2.1: "make ... easier" seems understated, presumably we
care about interop, security, scaling etc. and it'd actually
have been easier (in a sense) to just have everyone follow
one vendor or open-source thing.

- 2.1, "It's intent" - the It's is a little ambiguous.

- 2.2.1, last bullet: I don't get that. Are real-time things
even in charter I wonder? (CHECK)

- 2.2.2, Better to use example.com, example.net than
FooBar.Inc etc unless there is a reason that the usual
examples do not work.

- 2.4, what is the impact for SCIM generally of "assuming"
use of LDAP here? If that's just an example, that's fine (but
it could be clarified), if it's more than that, then it'd be
good to know what exactly is meant.

- 3.1, file permissions seem to me to be out of scope of
SCIM. Changing UIDs, UUIDs, or similar is in scope though but
this section doesn't make that clear. (Put another way: I am
correct that SCIM is not NFS, right?  :-)

- 3.3, as per my comment on 3.1, this is unclear as to what
is in or out of scope of SCIM.

- 3.5 you say "selected attributes" a number of times.  Don't
you need to say by whom and when?

- 4: it'd be good if this explicitly called out that there
can be privacy issues here that go beyond transport security,
e.g. moving PII offshore between CSPs. I don't think you need
say more than that, but it'd be worth doing I think.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-scim-use-cases-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows) to Informational RFC


The IESG has received a request from the System for Cross-domain Identity
Management WG (scim) to consider the following document:
- 'System for Cross-domain Identity Management (SCIM) Definitions,
  Overview, and Flows'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides definitions and an overview of the System for
  Cross-domain Identity Management (SCIM).  It lays out the system's
  models and flows, and includes user scenarios, use cases, and
  requirements.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
=======

Document shepherd: Morteza Ansari
Responsible AD: Barry Leiba
Publication type: Informational

The SCIM use cases document (draft-ietf-scim-use-cases-03) covers the core set
of use cases discussed in the working group to be used as guidance in
developing SCIM schema and API documents.

Review and Consensus
====================

The document has been reviewed by the working group and . The active
contributors is mostly done by a relatively small number of vendors.

The current documents represent use cases for "version 2.0" of an existing
standard that was developed at OpenWeb Foundation. The document has gone
through WGLC and all comments were addressed during the WGLC. It is the view
of the shepherd that the document should be published.

Intellectual Property
=====================

No issues

Other Points
============

There are no downref issues.