8/12/2011 Conference Call Notes 4-5pm EDT

Attendees

• Rob Carter, Duke University (convener)
• Keith Hazelton, University of Wisconsin, Internet2, Bamboo Project
• Tom Zeller, University of Memphis, Internet2, Unicon
• Lucas Rockwell, UCSF, UC System

• Introductions

• Rob: Duke University - convener (because Tom Barton didn't want
  Keith to leave Chicago with two groups to convene
• Keith: Wisconsin and Internet2, but heavily involved in IAM needs
  of the Bamboo Project, and willing to try out our ideas with
  the Bamboo participants as that becomes possible.
• TomZ: Memphis, I2, Unicon – working with both the Grouper project
  and the Shibboleth project, with strong interest in how SAML
  may play in this space
• Lucas: UCSF and the wider University of California system, which is
  looking for system-wide solutions in the IdM space now

• Agenda bash

• Rob: We have roughly one month to produce a report back to the larger
  group from Chicago, so we'll need to make some quick progress in
  framing up the problem we're presented with. To that end, the
  first call's agenda includes discussion of goals for the next four
  weeks (putatively, framing the scope of "provisioning" in this
  context, refining a gap analysis within that scope, and developing a
  high-level solution strategy for the space that we can advocate to the
  wider Chicago group. We also need to consider organizational
  matters, and look at setting some very short-term objective as AIs
  for the next call (probably in a week).
• There was general agreement to the agenda as proposed.
• TomZ: will have to leave around 4:30 ET for another engagement.

• Scope

• Rob: Should we take a few minutes to discuss the background from the
  Chicago meeting, since Lucas wasn't able to be there (just to make
  sure we're on the same page)?
• Lucas: would find it helpful
• Rob: Shall I take a stab at it, or would someone else like to?
• Keith: wanted to hear Rob's take on the meeting
• TomZ: Go for it.
• Rob: In overview: A bunch of us realized that lots of our institutions have
  critical needs in the area traditionally addressed by commercial
  products that call themselves "identity manager" solutions. Many of
  us are either looking for solutions because we've reached the point of
  needing better support in this area. Many others are shopping for
  alternatives in the aftermath of the Sun/Oracle merger. Many schools
  have done home-grown solutions in the space (mostly only
  addressing their own most pressing needs) but have found little in the
  way of shared open source alternatives. Meanwhile, some larger
  open source projects (notably, the Kuali project) are reaching the
  point in their lifecycle at which they need to address IdM issues
  and are considering development in the space. Some of us agreed
  that it might be worthwhile to get together and see if some cooperative
  effort might be possible in this space, and if there might be some
  points of convergence we could take advantage of.

In the discussion, we ended up identifying about eight high-level
components of an IdM stack that we felt were significant for higher
ed. After a prioritization exercise, we settled on three technical and
one organizational priority to try and address first, and formed sub-
groups to start considering each one in greater detail. The top three
technical priorities were:

• Registries. Our sense of this space was that it would
  encompass the part of an IdM stack where source data
  (probably coming in from multiple authoritative sources)
  would be collected, stored, merged, deconflicted, potentially
  used to synthesize additional identity data (roles, for
  example). We pluralized the word in recognition of there
  potentially being multiple registries – users, clearly ,but
  possibly other types of identities, as well.

• Access Management. Our sense here was that this group
  would think about how the identity information in the
  registries gets translated into a form usable for making
  access control decisions, and how systems that need to
  make those decisions interact with the data in order to make
  them consistently and quickly.

• Provisioning. This is our present group. In the Chicago
  discussion, there were actually two distinct areas discussed;
  provisioning and data presentation. The distinction
  between them was largely the distinction between "push"
  methodologies and "pull" methodologies – "provisioning"
  was used as a proxy for the "push" methods – ways in which
  data in the IdM (in the repositories) would be pushed out to
  other systems (perhaps in the form of account creation,
  perhaps in the form of data synchronization, or perhaps in
  other forms). Data presentation was to some extent a proxy
  for "directory services", although it frequently was discussed
  as including things like query APIs. One of the questions
  we will need to answer is whether our view of provisioning
  will scope the "data presentation" portion of the space
  in or out of view – it could easily be considered part of our
  scope, or as a separate issue all to itself.

• Lucas: background was helpful – just to clarify – which of "push" or "pull"
  are we saying is definitely in scope?
• Rob: I think "push" is automatically in scope for our discussions – if we
  want to also discuss "pull", we can, but if we want to limit ourselves
  to "push", it's probably OK for us to do so.
• Keith: Would hope that pull can be in-scope for us. SCIM has both push
  and pull semantics defined for its approach. Also, is it in-scope to
  discuss as part of provisioning how we get data into the
  provisioning engine – whether we use hand crafted connectors for
  each source system or somehow try to standardize an interface for
  incorporating data into the engine?
• Rob: A good question – I could see two different questions, really – one
  around whether the provisioning engine takes data only from
  the registries (where it may have arrived from lots of other
  source systems) or whether the provisioning engine takes data
  from source systems as well, and one around whether the
  input of data to registries is par tof the registry discussion or
  part of the provisioning discussion. I could see it going either
  way, logically, although I have a bias (coming from an OIM
  background) for separating the two into provisioning (which
  just covers the flow of data from the registry to other systems)
  and reconciliation (which is Oracle's term for the loading of
  data into the registry). The two can certainly be treated as a
  single whole, though.
• Keith: Right - both are possible, and architecturally, it's just a box with
  an "in" side and an "out" side.
• Lucas: Calling out the difference between the two is important and useful.
  Provisioning (IMO) is more geared toward getting data from the
  registry to subordinate systems, not necessary getting it back to the
  sources. Data synchronization is perhaps another phrase for it.
• Keith: In the end, our goal is an open source IdM stack that works, so
  the interaction between the registry and the provisioning engine is
  critical – input to the provisioning engine has to be addressed from
  one of the two sides (whether by the registry folks or by us). Getting
  source data into the registry to begin with is another issue that's
  distinct, but…
• Rob: Agreed – regardless of anything else, the interface by which data
  gets from the registries into provisioning tools/services is
  critical, and needs to be negotiated between us and the
  registry folks, no matter what. Depending on our and their
  opinions, getting data into the registry could be construed as
  just another kind of provisioning task (this time from a source
  system into the registry).
• Keith: Right – the same tools could be reused there potentially, but what
  we're really worried about at this point is the interface between
  us (provisioning) and them (registries).
• Rob: Since Tom needs to leave soon – did you have any early thoughts to
  add before you have to go?
• TomZ: A picture would be useful – even if really simple and really high
  level – to describe what we're talking about. it should
  include both push and pull mechanisms, and should mention
  moving info around within the organization across the
  different components. It should include provisioning within
  the organization as well as across federations and into the
  cloud. We can use the wiki to house some of this initial
  documentation. In Cicago we talked about sending a message
  to folks to describe what we're doing – ti would we worthwhile
  to poll people outside the group about what they're doing in
  this space – Surfnet is working on some stuff with a group in
  Finland, UNC-CH did some work with SPML not too long ago,
  some folks from the EU seemed interested in an approach
  similar to what we're doing (an open source IdM "stack"). If
  we put together a picture and distribute it, then we can use it
  to poll and see who's interested in the space and who's doing
  something already that's of interest to us.
• Rob: Definitely worthwhile to get a picture early on.
• Tomz: Niels from SurfNet has a good picture in this space – I can
  find a link and forward it to the group. SCIM has some good
  documentation of information flows as well
• Keith - the SCIM link should be out in email to the group – perhaps good to
  go review the SCIM model and see where we think it might
  fit or not fit in our use cases.
• TomZ: SCIM has gone a long way but has a few gaps left to address – its
  primary gaps are probably in the area of handling merges of
  identities (editor's note: I'm guessing this referred to what
  we at Duke call "consolidations" – where one individual ends
  up with two identities and needs to have them collapsed into
  a single identity?) Also there is work toward developing a
  concept of roles and entitlements in SCIM – Chris (editor's
  note: Which Chris?) is advocating they consider both
  roles and groups… Their strategy on and position around
  entitlements isn't as clear yet… Perhaps we can provide them
  clarifying use cases in some of these areas.
• Keith – That's definitely concrete, and worth some effort. It's not clear if
  SCIM will catch on or not, but we can at least bet on it and
  to give them good advice when we can. Perhaps take as a
  a goal tracking the SCIM project and providing input on
  the university / VO cases that drive needs for things like
  merging and entitlements.
• Tom – would be nice to work out some use cases using different solution
  models – saml, spml, and SCIM – to show how they each
  might work. In the end, there might be more than one type of
  box in the middle.
• Rob: definitely – we don't have to envision a one-size-fits-all
• Keith : Also something that we can discuss in the strategy group on the
  next call.

• Tom had to leave the call at roughly this point…

• Rob: We should probably address some of the organizational questions
  with our remaining time. So far, we've gone longer than I expected,
  but the discussion has been fruitful.
• Keith: The extent of discussion on this first call suggests we have some
  of the right people at the table, at least.
• Rob: Definitely – so discussing organizational trivia, do we:

(a) want a mailing list? - All: yes (Keith: archiving would be good too)
(b) want to use the same wiki page - All: yes (if we need ore pages
we can always create them
( c) Concalls weekly? - All: yes (given our short time frame)
(d) Concalls on this bridge at this time each week? All: yes

• Rob: Good enuf. we need to document AIs for the next call in a week,
  then. How about:

+ *Rob: Take a first stab at drafting a picture of the overall
architectural diagram and how we fit in it.
Rob will use Graffle to produce a high level diagram*
+ *All: Review the documentation from the SCIM project, particularly
the SCIM scenarios documentation, and see where you think
there are gaps between our needs and the use cases/
scenarios SCIM is addresing.*
+ *Keith: Will send out URLs for the SCIM documentation and web
site for us to review*
+ *Rob: Will send out some other items for though before the next
conference call.*

At this point, we adjourned for one week, to return on the same conference bridge from 4pm - 5pm ET August 17th for a followup call. Expect emails during the week leading up to the next call.

;rgc