June 5, 2002
Attendees

* Steve Worona - Educause
* Eric Norman - Wisconsin
* Neal McBurnett - Internet2
* Renee Frost - Michigan/Internet2
* Judith Boettcher - CREN
* Jim Farmer - CREN
* Bob Brentrup - Dartmouth
* Chris Misra - Massachusetts
* Michelle Gildea - CREN
* David Wasley - UCOP
* Jim Jokl - Virginia

Discussion

Jim started the call by explaining the Ben has been ill so we do not yet have minutes from the previous call and will not have someone on this call to capture minutes.

The majority of the call was devoted to discussing proposed changes to the certificate profile to incorporate the U.S. Department of Education's OPEID identifier number (sometimes called FICE code) and the Federal Institutional Entity Identification Number (EIN) into the profile.

Advantages for having this data in the certificate include:

1. The identifier is guaranteed to be unique and thus does a better job of identifying a particular institution than the naming that we presently specify in our profile.
2. Applications involving interactions with the federal government will be easier to design and deploy.

The early stages of the discussion focused on how often these identifiers might change. The idea was that it might be reasonable to add relatively static information to the certificate but data that could change frequently is not appropriate due to implications for revocation and issuing new certificates. If the data is static, the main question revolved around if the pain of extra clutter in the certificate is outweighed by the benefit to applications.

The question of if the proposed data really is static was next discussed within the context of where to locate the data in the certificate. If the OPEID/EIN numbers apply to the Issuer, everyone was comfortable that the data was indeed static. If instead they are meant to apply to an End Entity such as a person or a server, the answer was less clear. Several potential issues for EE certificates were raised:

1. The institutional affiliation for students, faculty, and staff changes frequently. Does having the OPEID and EIN in the certificate imply affiliation on the date of issuance or throughout the lifetime of the certificate.
2. What about campuses that intend to issue certificates to a wider definition of members of their community beyond traditional registered students, faculty and staff? Is there a definition for when this data should be included and/or when it should be withheld?
3. If for a server certificate, what about servers with multiple roles where some of these roles are official and others are not? How is an individual server identified as the authoritative campus server for any specific role?
4. Would it be more appropriate to retrieve this information from an associated directory instead of storing it in the certificate itself?

The group decided to delay action on this topic after much involved discussion. The plan is to discuss the issues again on the next call and/or via email using examples of anticipated applications to guide the discussion.

The group next had a brief discussion on form and document signing tools. There was sufficient interest in the topic to warrant some work in this area. The group decided to discuss this topic again on the next call when more people who have looked at tools were likely to be available. TAG will probably choose to at least add information to the web site on available options and strengths and weaknesses of the various solutions that different campuses are investigating.