A. Name: Policy on PennNames Compliance
B. Number: 2005mmdd-pennnames-compliance
C. Author: M. Muth (ISC Networking)
[ ] proposed [X] under review [ ] approved [ ] rejected [ ]
E. Date proposed: 2005-03-16
F. Date revised: N/A
G. Date approved: N/A
H. Effective date: N/A
II. Authority and Responsibility
Information Systems and Computing has custodial
responsibilty and accountability for the University of Pennsylvania's
PennNames service which is
integral to the operation of the Penn-wide user namespace.
III. Executive Summary
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.
V. Risk of Non-compliance
If PennNames are not handled in compliance with this policy,
unauthorized access to systems, applications, and/or data may occur.
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
- 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
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
- 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 employee ID number. PennCard holders will
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 handling of PennNames by PennNames-compliant
systems and services.
VIII. Statement of policy
- Any name used by a system or service must be sponsored, if that
name falls within the PennNames namespace.
- Any use of a PennName in a list of named authorized users must be
- An individual who is assigned a PennName must be assigned a
single, unique PennName by a sponsor.
- 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.
- 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
- Application owners must register and relinquish sponsorship of
PennNames using the PennNames service (see http://www.upenn.edu/computing/pennnames) since sponsors will need to be notified in the event a
- A system that is PennNames-compliant adheres to requirements of the
Policy on the Duration of PennNames (http://www.net.isc.upenn.edu/policy/pending/2005mmdd-pennnames-duration.html).
IX. Recommendations and Best Practices
- Local support providers (LSPs) should encourage users to select
their PennName carefully, since opportunities for change are extremely
- 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.
- 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.
- 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
- 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
(http://www.net.isc.upenn.edu/policy/pending/2005mmdd-pennnames-duration.html). 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
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
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,
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.
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
Network Policy Committee (NPC). The NPC will recommend a resolution. If
either of the parties reject the NPC'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.