Identity in the Clouds TC - notes on member comments, corrections

[James Bryce Clark <jamie.clark@oasis-open.org>]

This is a set of observations from one member of OASIS staff, on the
posted Identity in the Clouds TC draft charter at
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/email/archives/201002/msg00000.html.
 These questions and ideas may come up during the upcoming convener
call.  In other words, I'm sending you my shopping list of questions &
 suggestions in advance of the meeting.

It's common for OASIS staff to inquire about various ways that a
charter could be clarified or augmented, after reading the member
comments.  However, the draft remains the property of its proposers.
It will be finalized with whatever provisions the TC co-proposers
choose, so long as it conforms to our rules.  So, any of these matters
would need the general assent of the members sigining the charter.
Still, it's not uncommon to make some polishing changes at this stage.

1.  We noted some references on the [oasis-charter-discuss] list to
time models.  Even though this proposed TC is named, that appears to
be a typo:  I believe those comments were intended for the Ws-Calendar
TC, also in process in February, and were not addressed to this
proposal.

2.  We also noted some critiques on the [oasis-charter-discuss] list
about whether the synthesis and analysis of other specifications, gap
filling analysis, and use case collection are appropriate activities
for a TC.  Many other TCs have engaged in similar activities.  When
operating in a re-use environment, this kind of analysis of the
landscape of existing work usually is considered good engineering.

3.  Personally, I think the plan to do gap analysis, and then
profiles, with a bias for interoperability and re-use, as described in
1c.4, 1c.5, 1c.6, and 1d.2. is the proposal's strength.  It may be
possible to make this theme of sensible adaptation clearer to a lay
reader, by doing two things.  (a) First, consider also stressing this
point in the prefatory material.  I have enclosed a possible minor
edit to the middle paragraph of section 1.b that might accomplish
that.  (b) Second, the true scope of the planned work seems to be
"identity management" (as stated non-normatively in section 1b), so
you may wish to port over that phrase to the normative section 1c.
See the attached mark-up.

What I am suggesting is that, in a binding scope clause, a phrase like
"identity [deployment, provisioning and] management in a cloud
computing context" is more meaningful and enforceable than "identity
in the clouds".

Whether "deployment" and "provisioning" are appropriate words is a
question for our conference call and your co-proposers.  I am
concerned that a reference to "management" only might be read quite
narrowly.

4.  The draft's definition of some of the other tasks seems a bit
mushy.  The scope section (1c.1) says that the TC "will" identify
terminology and vocabularies, and threat analyses; but the
deliverables section (1d) does not include any such deliverable.  I
suggest you add optional ones, so this does not look like a mistaken
omission.  See section 1d.3 of the markup.

5. Similarly, the scope section (1c.2) says that use cases -- of some
unspecified type -- will be defined, and these are to be completed by
July 2010 in the deliverables (1d.1).  But use cases of what?  I
suggested adding the more specific phrase here.  See the mark-up.

6. In Section 1c.6, this statement reads too much like a binding
instruction to another TC:  "then the work will be undertaken by the
SAML or WS-Trust TC."   I have suggested an edit to this, and to the
related sentence in the "Out of Scope" clause, to clarify this, and to
correct the inaccurate TC names.

7.  The statement about liaison in section 1b (whuch reads like it
dictates the form of an external OASIS relationship) needs to
acknowledge the relevant OASIS policies.  Also, the ITU-T is not an
indusrty fora.  See the markup.

8.  The draft's first list of out-of-scope items (access control, LOA
and PII) may make sense to identity experts, but possibly not broader
readers.  I have suggested a clarification, in the markup.  I assume
the TC's taxonomies and profile *will* be permitted to reference pther
existing implementations of those concepts.  In other words, it's new
work in that area, not compositions that include existing work, that's
out of scope. Let's confirm that at the convener call.

9. Our open standards community usually expects us to be aware of the
existence of other cognate or related works.  We frequently give
careful review to that aspect of TC proposals.  Section 2a seems short
of the usual cross-references.  I have added a few, in the attached
markup, noting those mentioned in the member comments.  A reference to
other work does *not* commit the TC to use it;   but it's usually
considered a more mature good practice to admit its existence.  This
helps us with later assertions of duplicative effort or inter-SDO
conflicts.

Thanks for your consideration.

Kind regards,  Jamie

~ James Bryce Clark
~ General Counsel, OASIS
~ http://www.oasis-open.org/who/staff.php#clark

IDClouds-charter-draft-jbc-comments.rtf