[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]

The schema defines an important specialization of Party-to-Party Relationships called Roles. Roles provide a way to define and add information about aspects of a Party that are specific to a given relationship. Roles are built in to the System.Identity schema. Other information can be added through Extensions. The right half of following illustration portrays Roles that a Party can play: Employee, Customer, Citizen, Vendor, Authority and ProcessRole. Whereas the specializations of Party are mutually exclusive, Roles are affiliated.


For example, suppose a Person is in an Employee Role with respect to a given company. There is almost always directory information that is specifically associated with playing that role. For example, an Employee is likely to have an office location, an email address and title specific to a given job. In Roles, the PartyId refers to the Party that “plays” the Role while the ContextParty refers to the one for whom the Role is played. Roles can have a StartDate, EndDate and Kind. For example, a Person’s entire job history at a given organization can be modeled as a set of Employee Roles between the same Person and ContextParty, retaining full knowledge of when each position began and ended. The same schema can model all the jobs held by a Person at multiple Organizations, or a single job at a single Organization, or even all the People who have held some job over time. The same Person can be represented through different Personas in different contexts – for example, a “home” Persona and a “work” Persona. When combined with the relevant Roles (For example, Citizen – potentially of more than one country.) information relevant to many aspects of a person can be represented.

It is normally not appropriate for an employer to assemble all the possible information about a Party who is an employee; yet representing this detail can be essential to building a directory useful for a person’s own cell phone or digital memory server or “location service” in the cloud. By ensuring the same schema is used everywhere, the appropriate information can be easily moved between instances and contexts when that is desired by the information subject, and an application can operate against any of those instances without modification.

With this approach many benefits accrue, and limitations on conventional systems fall away as shown in the following examples:

  • A Person can be a Customer (play a customer Role), but an Organization can be a Customer too (many organizations have both kinds of customer). Most modules of an application that deal with such “customers” would not have to know what Kind of Party a given Customer Role attaches to - or contain multiple code paths to support this. In other words, they would relate to the Role and to the Party in general – not to information specific to a particular Kind of Party.

  • A Group can be a subject (access services) by virtue of being a Party. A Group can have members of any Kind – such as People, other Groups or even Organizations or Services (as would be the case in a federation of organizations). It is a fundamental simplification that a common authentication and naming model can be used across all Party and Role instantiations.

When considering Roles, it is natural to ask how they relate to Role-Based Access Control (RBAC). This schema treats RBAC Roles (which are played within some process or workflow) as yet another specialization of the more general Role concept; they are instances in their own ProcessRoles Extent.


The schema distinguishes between a Person’s Personas in the same way it does between Roles. Personas are like Roles played by a person, except that the context is not one specific Party, but rather something more dynamic (the subject selects whatever Persona seems appropriate to a context).

Fill out a survey about this topic for Microsoft.