Identity Keys

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

The schema must facilitate unambiguous naming of Parties and their Roles within multiple namespaces and using different schemes. Further, it must be possible for Parties to authenticate themselves as legitimate bearers of their names and to verify that other Parties are who they purport to be. This is handled through the notion of IdentityKeys. IdentityKeys are by their nature of different Kinds.

There are many different ways to name Parties. Common ones include email address, network account name, DNS name, GUID, PUID and SID. In the System.Identity schema each of these Kinds of name is represented as a Kind. New Kinds can be added easily that represent new naming schemes.

Each IdentityKey instance has a Kind property that is the identifier (ID) of the Kind, as well as a Value that is the specific name or identifier of the instance. For example, an IdentityKey instance with a Kind of RFC822Mail might have a value of kimabercrombie@adatum.com. Further, an IdentityKey includes the PartyId of the Party it identifies. For example, the IdentityKey just described would contain the ID of a Party that represents Kim Abercrombie.

IdentityKeys, no matter what their Kind, all allow efficient location of the corresponding Party. IdentityKeys also allow a name in one namespace to be easily and efficiently converted to a name in any other. IdentityKeys support multiple names, name changes and the introduction of new naming types. Thus they satisfy a number of the most important requirements of a directory from a capability and performance point of view.

Id	PartyId	Kind	PartyRoleKind	PartyRoleId	DateRange	Value
1023	24	Email	Employee	10223	Jan - ?	danpark@adatum.com
1024	24	Email	Persona	19420	Jan - ?	johnkane@contoso.com
1045	24	NT Name	Employee	10223	Jan - ?	DOMAIN\user
1025	24	SID	Employee	10223	Jan - ?	S-1-5-21-1454471165-1004336348-1606980848-5555
512	24	SID	Employee	10223	Apr – Jan (Expired)	S-1-5-21-1454471789-2302346348-1609890848-1234
299	56	Email	Persona	7942	Aug - ?	jefflow@adatum.com
301	56	Phone	Employee	15009	Aug - ?	+14255550100

For example, suppose someone logs in with the identifier “DomainName\username” and it is necessary to obtain a Security Identifier (SID). One would query the Extent for the IdentityKey of Kind “SID” whose PartyId and PartyRoleId match those in the IdentityKey of Kind “NT Name” with a Value of “DomainName\username”.

When the requirement is to locate the Party that corresponds to an email address, it can be met by selecting the PartyId from a “currently valid” IdentityKey of Kind “email” with the address as its value. This would work for any of the Party’s email addresses.

The phone system would select PartyId from the currently valid IdentityKey of Kind “Phone” with the phone number at its Value. Thus the query is identical to the previous one except in its parameters.

Using IdentityKeys to Disambiguate Roles

When an IdentityKey is associated with a specific Role, the PartyRoleKind is set to the Kind of the Role. This records what Extent specializes the Role. The PartyRoleId is then set to the ID of the Extent instance.

This is illustrated in the first line of the previous table, where the IdentityKey points not only the Party that represents Username but to the Employee Role that represents his work at Organization. Thus the IdentityKey’s PartyRoleId contains the ID of Username‘s Employee record. Using this mechanism, a given IdentityKey resolves efficiently either to a Party or to a specific Role – or to both.

Authorities and Tokens

IdentityKeys can also explicitly specify the Authority that issues them. An Authority is actually just another Role played by a Party. For example, an organization might operate an Active Directory-based Kerberos authentication network. Then a network login name IdentityKey of the Organization’s employee might specify the relevant Kerberos system as its Authority.

Further, multiple Tokens can be associated with any IdentityKey. Tokens have a Foreign Key called IdentityKeyOwner that contains the ID of an IdentityKey instance. Tokens are also of given Kinds. For example, multiple Tokens of the “Certificate” Kind might point to a single IdentityKey of the “X.500 Distinguished Name” Kind.

For another example, consider the table just discussed. A Token of Kind “Password” that contains a function of a password might point to the IdentityKey of “NT Name” Kind shown in the third Row. Then joining the IdentityKey instance to the Token Instance allows the password to be verified.

The DateRange field within the Token allows the schema to retain knowledge of expired passwords to prevent password reuse.

IdentityKeys Identify Uniquely

Note

All identifiers are stored as IdentityKeys. This includes identifiers traditionally stored as simple properties, like telephone numbers. As stated previously, incoming telephone calls can be used to identify callers, and are as much names as anything else.

Cell phone numbers are associated with individuals, so modeling them as IdentityKeys makes sense, but considers the case of residential phone numbers that are shared by multiple People. For this reason, home phones should really be associated with a “Household” – a Kind of Group to whom a Person belongs. There are many cases when applications can benefit from knowing a number is connected to a “Household”, or that a call may be from one of several different people.

Fill out a survey about this topic for Microsoft.