Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Advice for Implementers 

This document offers advice to implementers looking to take advantage of the eduPersonDisplayPronouns attribute. This attribute offers a way of transmitting (and storing if used in a directory context) personal pronouns as a human being would like them to be displayed to support their use in applications that are capable of consuming it for display purposes to other human beings. In English, this pattern commonly has the pronouns following one's name (eg: "he/him/his"  following "Ashe Winters"). The attribute value, while in some languages written as "subject/object/possessive" (e.g., "she/her/hers" or "ella/la/su"), is a free-form string and must not be assumed to take any particular form or set of values.  Other values could include (but are not limited to): "ask me" or "prefer not to state" or "use first name."

Different languages treat the entire concept of pronouns differently, and the group who contributed to this document do not represent experience with all languages. Additional feedback representing additional language behaviors is more than welcome; please submit an issue to GitHub.  The guidance offered here regarding where and how to store pronoun choice for use in third-party services is intended to apply internationally and so does not make any specific recommendation regarding which pronouns an organization should support. That must be a decision made locally and in accordance with local language and cultural requirements.

Specific Guidance

  • Avoid appending pronouns on attributes such as displayName/cn or givenName/sn and causing awkward UX designs like, "Hello, Ashe Winters (they/them/theirs), welcome to XXX" or as "Winters (they/them/theirs), Ashe" while enabling applications interested in displaying my name and pronouns to others (e.g., Zoom) to show "Ashe Winters (they/them/theirs)" or "Winters, Ashe (they/them/theirs)" as appropriate to context.
  • Because this is not a fixed value set, implementers using directory services are advised not to index the values.
  • How you implement the UX to take advantage of this attribute is going to vary from one organization, and even one system, to the next. The attribute itself is single-valued and not designed to be machine parseable. 
  • Identity Providers are encouraged to support attribute-level consent to allow people to choose whether this attribute is released on a service-by-service basis to protect the individual’s rights to privacy. 
  • Service Providers are encouraged to support the use of this attribute, but to also allow for service-specific overrides.  If the SP detects a change between their local value and the attribute value, they should make an explicit ask of the user if they want to update their service-specific information. 
  • The UX should include information for the user regarding what security and privacy practices are being followed to protect this information and how this attribute is intended to be used.
  • This attribute should NOT be a mandatory field for users to fill out.
  • Information in this attribute should be treated as personal information and afforded the same protections as data such as age, ethnicity, religion, etc.

FAQ

My institution wants to use a predefined list of pronouns, how should I implement this?

...