Three types of certificates, distinguished by their level of user identification, will be issued.

NetID and/or CampusID included

CampusID only

No ID, i.e. anonymous, may include demographic information as defined by University contracts and is optional.

Each campus maintains a single CA for personal certificates.

UCOP will maintain the anonymous CA which will accept a personal certificate from a campus and issue the anonymous certificate.

The committee recommended a standard server naming convention for campus authorization servers in the format, auth.domain, i.e. authorization.ucop.edu.

Task: Define the relationship between Office of the President

The University Directory will provide three fields which will provide a pointer to an authorization server. Initially these fields could include the CampusID.

The NetID is independent of the CampusID. Any relationship between the two will be defined and maintained at the campus level.

The campus directory servers probably will not include the full systemwide Directory. The University Directory needs to include information to which points a campus application to additional authorization information.

DECISIONS

Multiple APIs must be available for obtaining authorization information. This workgroup will not define the interface into the authorization system at this time.

The Universitywide interface into directory services will be through secure LDAP or HTTPS.

The University Directory needs to provide a mechanism to associate individuals with multiple location to accommodate individuals that have relationships with multiple campuses?

UC certificates will have a strength field in the payload.

Strength values and their meaning need to be defined by a follow-up workgroup.

The following strength scale is provided as a reference.

The strength field will use a scale from 1.0 — 10.0. The meaning of the integer portion of a number will be agreed upon Universitywide. Campuses can use the decimal portion of the number to provide a campus defined level of refinement to the scale.

Strictly for the purposes of beginning work on pilot applications the following values are assigned.

7 = a generic form of PhotoID

3 = a generic, automatically generated certificate

Summarize all activities and conclusions. Recommend a process

for completing the CPS.

David Wasley has been asked to draft a policy document that will

address all areas that might affect the authentication project.

These include:

Summarize campus implementation plans which will be complete by September 30, 1998 to assist UCOP in Melvyl and BENCOM application development planning.

Melvyl will use the NetID in the certificate.

Frank and Sal will define the certificate payload with the UCSD OID and extensions.

UCOP is submitting an application for an OID.

Four campuses, UCD, UCI, UCLA and UCSD, have a certificate server available and ready to work with UCOP on the MelWeb and Bencom applications.

Each campus was asked to send project planning dates which require the deployment of certificates to a population outside of the test pool.

Each campus was asked to identify when daily updates will be required from the University Directory.

Sal Gurnani will schedule a meeting of the campus directory service managers, University Directory developers and MelWeb and Bencom developers. Each Authentication Workgroup campus representative will contact their local directory services manager about representation at the meeting.

The committee discussed the importance of the workgroup and recommendations for continuance of these planning activities.

The Steering Group has a meeting scheduled for June 25. The workgroup will provide a fairly complete draft to the Steering Group by June 22.