Personal names are complicated. This page is not intended to provide a comprehensive guide as to why, but wikipedia and other sources go into more detail. By way of an overview, though, Registry is designed to work with use cases such as
- Multiple names for the same person, depending on context
- Names recorded in different languages/scripts
- Names consisting of a single component
Date Model Elements
The underlying Registry data model consists of several fields.
The name itself is composed of up to five segments: Honorific, Given, Middle, Family, and Suffix. While this doesn't cover every possible use case, it does cover most. The minimum required field is Given, which mostly aligns with how mononyms are treated. Note this is contrary to LDAP, where the person
schema requires sn
(surname) but inetOrgPerson
layers givenName
on top as optional.
An additional Display Name may be set for each Name object. If populated, this field will be used whenever Registry needs to render the name, regardless of what is populated in the other five components.
Primary Name
Each Person must have exactly one Primary Name at all times. The Primary Name is used by Registry whenever it is necessary to render a subject's name. Provisioners may elect to use the Primary Name indicator for their own purposes, but are not required to.
The Primary Name cannot be deleted. Another Name must be flagged Primary first.
Permitted and Required Fields
It is possible to set which Name fields are permitted and which Name fields are required, via Configuration > CO Settings. These settings apply to Name collection in all contexts.
Default Name Type
When adding a new Name via the UI, it is possible to set the default value for the Name type via Configuration > CO Settings.
A Note on Naming of Name Fields
The main name components are typically referred to as first/last, given/family, or forename/surname. None of these are ideal. Registry specifically uses the given/family terminology because it is not position dependent. That is, first/last represent different components depending on the language selected (typically, but somewhat inaccurately, referred to as Western or Eastern name order). given/family avoids this problem. However, the term given is not ideal either, as it may convey an association of a name given to an individual at birth that the individual no longer wishes to maintain.
Unfortunately, there are no perfect options. In the Registry context, a deployment may use localizations to change the rendering of a field name as presented to the user, and this provides a workaround where the term Given is undesirable. In contrast, the use of first/last or forename/surname in the data model itself would lead to contextual confusion about which field refers to which name (depending on which language is in use), and that problem is not so easily worked around.
See Also
Changes From Earlier Versions
As of Registry v5.0.0
display_name
is now available.- External Identities no longer have Primary Names.