Page tree
Skip to end of metadata
Go to start of metadata

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 (and External Identity) 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.

(info) 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 ConfigurationCO 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 ConfigurationCO 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

Prior to Registry v5.0.0

  • display_name was added in v5.0.0.
  • No labels