Party

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

The directory stores information about digital subjects and resources that have relationships. Different kinds of digital subjects typically share many of the same characteristics – while being different. The System.Identity schema provides a single mechanism for defining all the different kinds of things present in the directory –represented through entities called Kinds. The System.Identity schema represents the common aspect of all digital subjects through an entity called a Party. It is then specialized as shown in the following illustration.

In the previous illustration, the Party has a name, a description, a time span and a primary Kind – examples of primary Kind are ‘Person’, ‘Organization’, ‘Group’, ‘Software Service’ or ’Device’. Parties can also have a secondary Kind – for example, an ‘Organization’ could have a secondary Kind of ‘Corporation’ or ‘Government’. It is essential to this schema that little of the information about Parties is stored as simple properties of the Parties Extent. Instead, the schema employs multipleExtents dedicated to storing identifiers, locations and Party-to-Party Relationships. Taken together the base schema delivers a rich representation of Parties. However, that representation is not intended to be exhaustive. The schema provides for additional PartyAttributes through which applications can store additional property sets. Applications can, if a given directory instance allows it, extend the schema of the repository to establish new extents that are associated with Parties of particular Kinds.

The System.Identity schema already contains a good example of how schema extensibility works in the way that ‘Person’ Parties are represented. It defines a Persona extent that contains personal information such as personal name, gender and photo, along with a Party ID (a foreign key that points to the ID of the Party to which the Persona belongs). This allows multiple Personas (potentially also of different Kinds) to be aspects of the same ‘Person’ Party (one of the Personas being marked as the default) by joining Persona to Party on PartyId, the Party identifier.

Parties also participate in Party-to-Party Relationships and play Roles. Representing the many aspects of a Party by decomposing them into Roles, Party-to-Party Relationships, Identity Keys and Locations provide many advantages. Contrast this approach with the current LDAP directory schema, where the definition of a person is a collection of attributes, like surname, address, manager and organizational affiliation. The fact that a person might have two jobs with two separate organizations and thus two different managers, or a sequence of jobs with different managers over time, cannot be represented in the model, limiting the use of LDAP directories in many ways (the chief of which may be that they are incapable of representing the world from the point of view of the individual who lives in it, which makes it hard for information to be replicated between the personal and organizational planes). The System.Identity schema reflects the fact that people (and other entities) are more multi-faceted than this.

Fill out a survey about this topic for Microsoft.