Allow Group Owners to preserve non-redudiation and identity management on GitLab.com

Problem to Solve

In #24605 (closed) we implemented a feature to allow self-managed Administrators to restrict users from changing their display names within the self-managed instance.

Organizations using GitLab.com are bound by various legal and regulatory frameworks, which share a common requirement to maintain the integrity of a user's identity for the purposes of non-repudiation, or ensuring that someone cannot deny they took some action.

Currently, GitLab.com customers cannot restrict a user from changing their name, which can cause gaps in non-repudiation requirements for auditing and compliance. Additionally, adding this feature in a similar way to #24605 (closed) would constrain a user outside of the GitLab.com group the policy is intended to support.

Further details

This feature is not yet available for .com customers and will require some thought about how we can support GitLab.com organizations in this way given the more complex nature of GitLab.com and the multi-group, mixed personal and professional use, membership of users.

Implementing a capability for Group Owners to restrict a user's ability to change their name has different implications for GitLab.com than for self-managed instances.

The intent of this issue is to discuss potential solutions to provide GitLab.com group owners with the flexibility they need to enforce company policies around identity management in a way that only affects users in their group(s) and does not pervade all areas of GitLab.com.

Further validation is necessary to determine if existing issues may be, in part or in whole, a solution for this problem, such as #34262 (closed) or #7626 (closed).

Use Case

• I'm a Group Owner who wants to ensure that employee-users of GitLab.com cannot obfuscate their name when taking actions in my group(s).

Proposal

This is a work in progress.