Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
January 12, 2005

*Participants*
Tom Barton, U. Chicago (chair)
John Ballem, Brown
Keith Hazelton, U. Wisconsin - Madison
Gary Brown, U. Bristol
Renee Frost, Internet2
Minh Nguyen, Stanford University
Steve Olshansky, Internet2
Ann West, EDUCAUSE/Internet2
Jessica Bibbee, Internet2 (scribe)

*Action Items* 
[AI] {Gary} will send a use case to the {grouper-dev} mailing list,
illuminating requirement for site-configurability of grouper access
privileges.

[AI] {Gary} will send a document to the {grouper-dev} and {signet}
mailing lists, detailing ideas for techniques to enable
site-customization of the UI.

[AI] {Blair} will review the API to determine the scope of potential
changes to method names to conform to getXX and setXX java beans
convention.

[AI] {Tom} will email {Lynn McRae} and {Minh Nguyen} with a set of
subject interface issues to prepare for an upcoming signet call, which
will be covered in the next agenda.

[AI] {Keith} will lead the next {Group} call on Wednesday, 26-Jan-2005
at 12pm ET.

*Discussion*
The Group discussed several UI <-> API interaction issues on the
agenda regarding Grouper development. What is the best approach to
mapping access privileges to field-level read/write privileges? The
following three options were explored: (1) Grouper class method to map
access privileges to field-level read/write, (2) GrouperAccess.has
method to report privileges in field-level terms, and (3)
site-configurability of access roles. {Gary} and {Minh} offered their
opinions and it was decided that option (2) might be the best way to
get a hold of the information and meet the broadest range of needs.
[AI] {Gary} will send a use case to the {grouper-dev} mailing list,
illuminating requirement for site-configurability of grouper access
privileges.

In terms of developing a DELETE privilege, it will be necessary to
create a use case to amplify its significance. The next step will be
to identify the context of such a use case. Further discussion and
feedback is encouraged on the {grouper-dev} mailing list.

The Group briefly discussed GrouperNaming methods to create & search
namespaces. A group management method should not be used to manage a
name space. It should be distinct and logical, even though their
underlying representation is similar inside Grouper. It was suggested
that Grouper be separated out of Grouper-Group, as it does not fit
into the namespace.

The next issue involving UI handling of subject attributes straddles a
fine line. We need to address the most common useful cases early on in
the development process. This includes placing people into groups,
which means looking people up in the subject interface, and presenting
enough information to confirm to the user that they did in fact pick
the right subject.  However, we also need to be careful not to make
too many assumptions, which could reduce the number of sites that meet
these requirements, and thus the fewer purposes actually met. We
should also consider that various sites are now planning to
incorporate not only person objects, but also person/schema types -
computer objects, for example. One possibility is to have a field that
indicates whether an attribute is displayable or not; sites can turn
it on or off, as best fits the description of their subjects. The
challenge of how to present it would also present increasing
complexities. How do we configure the UI to know which attributes to
display for various subject types, beyond person?  {Anyone} is welcome
to send their ideas to the {grouper-dev} list, with regard to the
approach and strategy that ought to be used for rendering this kind of
information about subjects in the UI. [AI] {Gary} will send a document
to the {grouper-dev} and {signet} mailing lists, detailing ideas for
techniques to enable site-customization of the UI.

What does the Java Beans compliance mean to Grouper? The idea is to
make it easier for people to work with the classes. In the UI, we
would be creating Java bean class, which is a sort of wrapper around
the API object. There is some preference for separating the user
interface to have its own object layer, which is independent of the
API and not coupled. We could add a layer, which means more code and
complexity; that separation, however, would be good concerning the
API. Such may not be the case for the UI. This object layer could be
put between the API and API client. It would be separated and
maintained on the side of the client, but it could also be maintained
on the API side. Where it is appropriate within the API, we should
consider using the get and set methods. Naming convention for methods
should ideally start with a verb, for example, use get, instead of
list. [AI] {Blair} will review the API to determine the scope of
potential changes to method names to conform to getXX and setXX java
beans convention.

{Tom} explained a few subject interface issues that will be presented
at an upcoming signet call. There may be a situation where a subject
wishes to apply its own security to filter a response back. Depending
on who is the querier, we need to make sure that we can pass the
subjectID of the querier to subjectType's adapterClass with the
appropriate result set filtering and access capabilities. Currently,
Grouper's query method does the filtering result set within its
security model.

Given that there is one person type and multiple authoritative sources
of the person objects handled by a particular implementation, what do
we do about a person type adapter class? Is it possible for the
Can/should/howto to support multiple sources for a single subjectType
(eg, multiple IdPs for 'person' subjectTypes)? There are some
federated ID issues buried within this that need to be addressed as
well.

What is the need for simultaneous searching across adapterClasses for
multiple subjectTypes? The Group will work on quantifying use cases
where one might want to search simultaneously for both persons and
computers, for example. Without an exemplary use case, it might not be
an applicable task for Grouper 0.6 to incorporate.

[AI] {Tom} will email {Lynn McRae} and {Minh Nguyen} with a set of
subject interface issues to prepare for an upcoming signet call, which
will be covered in the next agenda.

The next MACE-Dir-Groups call will take place on Wednesday, January
26, 2005 at 12pm ET.