*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- U Chicago
Scott Cantor -- OSU
Renee Frost -- Michigan/Internet2
Michael Gettes -- Duke
Paul Hill -- MIT
Mark Jones -- UTHSC-H
Bob Morgan -- Washington
Steve Olshansky -- Internet2
Barry Ribbeck -- UTHSC-H
David Wasley -- UCOP
Bill Weems -- UTHSC-H
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

InCommon Identity Attributes Document Revisions

Bob radically restructured this document in order to help it fit in with other advice and comments delivered to InCommon participants. Given that it's linked to from the dry legalese of the participation agreement, he modified its style to a bulleted format to match. The term "identity attributes" is used liberally to mean anything regarding an identified entity, and are not to be interchanged with identifiers. Scott thought it best to clarify their meaning by calling out that not all identity attributes personally identify a unique individual.

There is no canonical way or place to write down information about representing eduPerson information as sent in SAML attribute statements. The urn:mace:dir:attribute-def URN registration page at least lists the names and forms some sort of registry.

Language was also added to the effect of, in Bob's words, "when you're using things that are defined by InCommon, use them the way you're supposed to. When you're doing things appropriate for these attributes, use them rather than doing other stuff." A level of indirection was suggested in adding a more technical attribute document to accompany the policy, rather than placing specific recommendations in this document.

A defined participant feedback mechanism was also suggested, but this may be served by or leverage a phone number and e-mail address provided by Internet2 for InCommon feedback and sprinkled throughout the rest of the documents and application process. Keith considered whether a collection of these questions could be useful for future iterations of the document, but was reassured that good suggestions percolate well and that architects are not allowed on help desks for everyone's sake.

eduMembership

A mockup UML diagram representing eduMembership was prepared for the group's discussion and appended to the agenda. This relationship connects individual entities to groups by creating a new eduMembership object.

Scott had an immediate comment that the attribute attached to eduMembership, eduGroupIdentifier, didn't make much sense on its own. He expected that eduMembership would include either zero or two attributes, in that it always represents a mapping between two objects. If there were zero, the relationship would be implicit, and any other attributes would describe additional conditions or descriptions of the membership. However, there was broad consensus later on the call that for simplicity's sake other attributes should be excluded initially.

The draft was modified to remove the eduMembership box entirely, and make the eduMembership object represented only by the line connecting the entity and the group. This is also a directional line, a consideration that is mostly important when utilizing groups that are
members of other groups. However, entities may be considered trivial groups of one, and the implementation of this as an LDAP attribute with a name membership requires a directional relationship. There are additional implementational issues regarding objects referenced that
aren't always objects in the LDAP directory, or have no DN, but that is a separate discussion.

Michael also was curious whether Grouper would be dealing internally with eduMemberships as part of the mappings from individuals to groups. Tom believes that Grouper doesn't need to touch eduMemberships directly at all. The impetus for this attribute, Keith elaborated, is
that Grouper will give a lot of relationships that need to be managed and expressed via LDAP and SAML; however, Grouper internally will
probably never see mention of eduMembership at all. Provisioners may be created to iterate over Grouper and create eduMemberships, or take groups populated by a student system in eduMemberships and form corresponding internal Grouper groups.

Reassignment & Federations

Bob's on record as saying that "must not reassign is a different kind of property than any of the others we've talked about." Is there some
sort of line crossed in stating that? It is difficult to specify that reassignment shouldn't be done without defining reassignment, which
implies the need to define how that identifier applies to some real-world entity. Bob doesn't believe there's anything in any
document currently regarding the relationship between MACE-defined constructs and real-world entities.

Some suggested that it might be possible to stop at saying it points to a record or object, and can only point at that thing forever;
whether that record or object maps to a real world entity is out of bounds? But, it became clear that if you assume reassignment of the
EPPN's that these refer to, the problem has only been obscured a level. Time may be another boundary that's been violated; if you say
eduPersonTargetedID is reassignable, that's one thing; specifying its storage in perpetuity is a policy decision which doesn't belong in an
attribute definition, according to Michael.

There has also been no discussion about persistance in the other direction; what if Paul is assigned one persistant identifier one day,
and the next day he arrives with a different one, but is the same principal to the same relying party? Can policies for attribute
management be different depending on the relying party -- maybe for eduPersonTargetedID, but not eduPersonPrincipalName?
Everyone on the call agreed that federations are a good and proper place to implement attribute retention policies, and attribute definitions are not.