*MACE-Dir Conference Call*
July 8, 2002

*Participants*

Keith Hazelton -- Wisconsin (chair)
Rob Banz -- UMBC
Tom Barton -- Memphis
Brendan Bellina -- Notre Dame
Scott Cantor -- OSU
Renee Frost -- Michigan/Internet2
Scott Fullerton -- Wisconsin
Bob Morgan -- Washington
Steve Olshansky -- Internet2
Jim Phelps -- Wisconsin
Bob Talda -- Cornell
David Wasley -- UCOP

*Discussion*

Wisconsin Roles & Entitlements

        There has been an effort at, in Keith's words, "concentrated
thinking" about how to do a better job with roles and entitlements.  The
basic model progresses from the original source of person information,
which will typically be something such as HR, student databases, etc.,
which generates a person.  The process can occur hierarchially.  This
person is then given an affiliation, which is mapped to a set of
entitlements, which are in turn used to grant access.  Throughout the
discussions, the group made an effort to mind which problems are mostly
political and which are mostly technical.  Keith expressed the view that,
if political problems can be solved technically, then it is important to
account for those in the design and support that necessity.
        More significant details were discussed.  Sources can include items
that are not derived from previous institutional data, as well.  The three
primary affiliations that were mentioned were student, alumnus, faculty,
each potentially branched with a major or area of study, although others
are being considered.  The person/agent structure and affiliation
structures are intended to be trees, e.g. member of community leading up to
a certain department leading to a certain affiliation.  This approach was
cited as allowing for structures as flat and bushy or tall and spiked as
necessary.  Other sources that may be considered in giving entitlements can
be placed in what has been termed the "adhocracy" tree.

Caveats

        Bob posed a handful of questions about the proposed structure.  In
reference to the first flows, he asked whether it were based on some
standardized concept, but this was developed by Wisconsin for this
occasion.  It was unclear to Bob what it means for a person/agent to be in
a tree, which the group agreed was an interesting concept which needed to
be further developed.  He also believed that most people sources would
provide affiliations along with other information, which is an important
piece of data to carry forward in the flows.
        The rest of the group made a general comment about the importance
of having a central person management service which all other services
defer to.  This is very handy in guaranteeing uniqueness, and the dangers
here of overlap are significant enough that delegation is a dangerous
prospect.  This avoids getting into the extremely messy and labor-intensive
business of matching and merging appropriately existing person records.
        There were also comments about when it is appropriate to add
entities to this central person registry.  If, for one research project,
researchers need to grant access to a set of people for a resource
protected by this system, do these individuals get entered into the central
person registry?  Other campuses want to maintain person records of all
applicants.  This sort of functionality needs to be supported somehow, and
it may not make sense to include these persons in the main registry.
Delegation of additions needs to be performed in some intelligent way as
well, since it's likely the student system will need to still be able to
add students, etc.
        The numerous special cases that inevitably arise on any campus
provide possibly the biggest challenge to any role-based system.  There are
students, for example, with undeclared majors, which would be very
difficult to classify and grant permissions to under the existing
tree-based structure Wisconsin proposes.
        There was also uniform agreement that perhaps the toughest policy
step will be going from roles to entitlements which all service providers
will be obliged to utilize to make their decisions.  Indexing a complex set
of privileges in current systems into a set of delineated, limited roles is
a great challenge.  Doing this by starting with service providers' needs
and current access rules and deriving a set of roles from them may be the
best approach.

Group Definition

        The group looked at what would happen if, for example, a campus
wanted to define it such that a bursar's system states who's back on dues
and then the metadirectory merges these with student data to make groups.
This is tough to accommodate with the current proposal.  One way to do it
would be to utilize an LDAP URL, but that embeds the knowledge in the
application, which is an unsavory step.  Another method would be to create
some sort of object outside the program which the program would be told to
retrieve, allowing for modular changing of the query, at least.  Under the
current Wisconsin system, it would be extremely difficult to find out, for
example, if a certain user were currently an undergraduate student.  The
ideal first level of indirection for this would be to invent a syntax for
policy queries like this, avoiding the necessity to create relational
database problems.