System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
RFC 7642

Note: This ballot was opened for revision 05 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2015-04-23 for -06)
No email
send info
- 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.

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

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-04-22 for -06)
No email
send info
- 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, 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.

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) (was Discuss, No Objection) No Objection

Comment (2015-05-07)
No email
send info
Thank you very much for addressing each of my discusses and comments.  The security and privacy consideration additions are much appreciated.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection