Retired-Policy on PennNames Compliance

I. Title

A. Name: Policy on PennNames Compliance

B. Number: 2005mmdd-pennnames-compliance

C. Author: M. Muth (ISC Networking)

D. Status: [ ] proposed [ ] under review [ ] approved [ ] rejected [ ] obsolete [X] retired

E. Date proposed: 2005-03-16

F. Date revised: N/A

G. Date approved: 2005-11-28

H. Effective date: 2005-12-06

I. Retired date: 06/01/2021

Information Systems and Computing has custodial responsibility and accountability for the University of Pennsylvania's PennNames service which is integral to the operation of the Penn-wide user namespace.

This policy specifies the requirements for PennNames compliance.

The purpose of this policy is to specify the requirements for systems and services to be considered PennNames-compliant.

If PennNames are not handled in compliance with this policy, unauthorized access to systems, applications, and/or data may occur. Access to University-wide services may fail or be impaired potentially resulting in inconvenience to end-users.


The set of all unique usernames that could be assigned on PennNames-compliant systems or services.


A PennName is a username which is unique to each individual at Penn. It may be used on multiple systems at Penn for that individual's accounts. Association between an individual and the individual's PennName is maintained using the PennNames service (see References, below). A PennName may also be a reserved name which is not explicitly tied to a particular individual. These are often used for mailing lists, aliases, or accounts not tied to a particular person ("role" accounts).


PennNames is a service to support migration to and maintenance of a common University namespace. It consists of a database, a set of system administrator tools, and basic policies.

PennName sponsor

This is a school, center or service that uses PennNames to register its use of a PennName for a service or system. A particular PennName may have multiple sponsors if an individual has (or had) access to multiple systems or services at Penn (see References, below), or if multiple systems have role accounts or mailing lists by the same name.

Penn Community

Penn Community is a database that provides biographic, demographic and affiliation information about people who are part of the University community.

Penn ID

A unique eight-digit number issued to Penn and UPHS affiliates. University offices frequently require a Penn ID as a unique ID, similar to an employee ID number. PennCard holders will find their Penn ID printed on their PennCard -- it is the middle 8-digit sequence of numbers. A Penn ID is generated when an individual is added to Penn Community, either manually or via feeds from SRS and Payroll systems.

This policy covers the handling of PennNames by PennNames-compliant systems and services.

  1. Any name used by a system or service must be sponsored, if that name falls within the PennNames namespace.
  2. Any use of a PennName in a list of named authorized users must be sponsored.
  3. An individual who is assigned a PennName must be assigned a single, unique PennName by a sponsor.
  4. A PennName which is used by groups or non-humans must be reserved, so that it will not be assigned to an individual as a PennName. A reserved PennName must be sponsored by each school, center or service that uses it.
  5. A PennName for an individual must have a Penn ID associated with it. A limited number of PennNames created prior to July, 2004 may not have Penn IDs associated with them, and they may not be reactivated until Penn IDs are provided. Furthermore, they may be released (made available for re-use) under the terms of the Policy on the Duration of PennNames (
  6. Application owners must register and relinquish sponsorship of PennNames using the PennNames service (see since sponsors will need to be notified in the event a PennName changes.
  7. A system that is PennNames-compliant adheres to requirements of the Policy on the Duration of PennNames (
  1. Local support providers (LSPs) should encourage users to select their PennName carefully, since opportunities for change are extremely limited.
  2. PennNames may be selected from a range of names generated by the PennNames server, or after querying a specific name to check availability. Both options are provided in the PennNames web interface and application programming interface.
  3. In cases where accounts are being created for a high-profile user, LSPs should work with the user to determine all available PennNames that would be acceptable.
  4. The existence of a PennName does not imply authorization status. Applications should perform authorization based on verified status using appropriate affiliation data from Penn Community or other sources of authorization data.
  5. It is important to realize that a PennName can change as a result of legal name change, transfer, or other conditions specified in the Policy on the Duration of PennNames ( This may result in someone losing access, and another gaining access inappropriately. Therefore, Penn ID is preferred for authorization because it is immutable.

A. Verification: Verification of this policy will occur during the course of troubleshooting.

B. Notification: Notification of compliance issues will be made to PennNames sponsors, associated LSPs and computing directors.

C. Remedy:Existing conflicts created prior to this policy should be resolved as soon as possible. A server or service with many names out of compliance may be deemed non-PennNames compliant and therefore experience loss of or limited access to University-wide services.

D. Financial Implications: The PennName sponsors and ISC bear the staff time costs associated with PennName compliance.

E. Responsibility: Responsibility for complying with this policy lies with PennName sponsors and ISC.

F. Time Frame: This policy is a formal statement of working policy that has been in place since 1997 (see References, below).

G. Enforcement: Failure to comply with policy may lead to a system or service being declared non-PennNames compliant, with attendant risk of loss of service.

H. Appeals: Appeals should be escalated within the affected organizations, for resolution by the respective IT Directors. If the conflict cannot be resolved, the IT Directors should present their cases in writing to the IT Policy Committee (ITPC). The ITPC will recommend a resolution. If either of the parties reject the ITPC's recommendation, they should take the issue up with the heads of their respective schools or centers. The Vice President of Information Systems & Computing should be consulted if further resolution is required.

    Policy Status
    Status Date Approval
    Retired 01/01/2022 ISC CIO - Tom Murphy