Understanding identity attributes
How identity attributes will support access, services, and data accuracy in Oxford’s identity service
Identity attributes are the key pieces of information that will be used to represent people in Oxford’s future identity service. This article explains what identity attributes are, how they differ from other identity concepts, and how they’re designed, stored, and used as part of the Identity Improvement Programme (IIP). It reflects current thinking and will evolve as the programme progresses.
Identity attributes sit alongside ‘groups’ and ‘affiliation groups’ as one of the three core data types that form an identity at Oxford. Together, these support more seamless and secure access control, more personalised services, and improved reporting.
What is an identity attribute
An identity attribute is essentially a piece of information about a person, representing a characteristic of the individual or their relationship to the University.
This can include system, staff or student IDs used to match records; names and preferred names; card details such as barcode or chip ID; and study or employment information, such as job title or contract or study start/end dates.
Attributes, groups, and affiliation groups
The Oxford identity service uses three related but distinct concepts.
- Identity attributes describe facts about a person, such as their preferred name or card barcode.
- Groups represent collections of people, such as project teams, group access to digital or physical resources, or licence holders.
- Affiliation groups describe a person’s relationship to parts of the University, such as departments, colleges, or contractual links.
Identity attributes are generally used for factual data about a person, while groups are used where membership needs to be assigned, managed, or reviewed. In some cases, the distinction is less clear, and technical design may influence whether a particular piece of data is best represented as an attribute or a group.
Why identity attributes matter
Well-designed identity attributes underpin how services operate. They help ensure people get the right access at the right time, support more personalised experiences, and improve security and audit. Non-unique attributes may also be used to derive group memberships, to describe characteristics at scale or to support appropriate access to management decisions.
Where identity attributes come from
Identity attributes come from authoritative systems such as Student, HR, Card, and Access systems. These systems remain the owners of their data but the IIP is bringing this data together so it can be matched, audited, and reused across the University for different purposes.
Only data needed for identity matching, access control, or defined service use should be treated as an attribute. Other data should remain in source systems because Oxford’s identity service isn’t intended to store all the data that exists about a person.
Where identity attributes are stored
Identity attributes follow a tiered storage approach based on how the data is used:
- Core attributes are held in Microsoft Entra ID’s standard attribute set, such as names, email, user principal name (UPN), and department.
- High-value attributes are held in Microsoft Entra ID custom security attributes to support critical authentication and access, particularly where attributes are widely used across the University.
- The Identity Vault is intended to be a centrally managed service that will store and manage identity attributes, providing greater flexibility, data history, and audit capability.
- Some data may remain in external systems, where central storage is not appropriate.
- Data is copied only where there’s a clear need for performance, availability, or integration.
How identity attributes are expected to be used
Identity attributes are shared through APIs (application programming interfaces) included in Single Sign-On (SSO) claims, and used in rules about entitlement that allow us to automate decisions about who should have access to what. In some cases, identity attributes may also be used to manage group membership automatically.
What this means for teams
For IT and service delivery teams, there are several benefits to this approach. For example, it:
- Provides clearer visibility of available identity data
- Reduces the need to maintain local data stores
- Enables other systems that use identity data to personalise experiences
- Supports more seamless and auditable access control
- Introduces faster and clearer routes for requesting and using attributes.
Next steps and getting involved
The IIP will continue to develop the design for attribute storage and exposure. It will also provide guidance on requesting and using attributes, and refine governance and tooling based on feedback.
Teams are encouraged to engage with the IIP team if they are designing or updating a service that uses identity data, need to manage access or roles, or currently store people data locally.
IT Services, DGU, and ITSS colleagues can contact digital.identity@admin.ox.ac.uk to find out more or get involved.