SIMPLEST schema entities and relationships.

["Gary.P.Cole" <Gary.P.Cole@Sun.COM>]

I promised to Jeff that the next revision of the SIMPLEST Profile doc would address references between entities, address the case of attribute names, and contain an updated list of attributes.  I still need to make another pass at the list of attributes and attribute names, but I wanted to send to the list a draft of some new "overview" text that introduces the schema entities and relationships.  That draft follows my signature.

Gary

The Person and Account schema entities are fundamental to Identity Management. An instance of Person normally represents a human being independent of any computer system or application. An instance of Account normally represents a person within the scope of a particular computer system or application. A person may own (i.e., be responsible for) any number of accounts. An inverse relationship also exists: an account may be owned by a person. SIMPLEST models these relationships by using attributes. An instance of Person may expose an “ownsAccount” attribute that may have multiple values. Each value of the “ownsAccount” attribute identifies an instance of Account for which the person is responsible.

NOTE: Many identity management systems conflate (i.e., fail to distinguish between) Person and Account. Therefore SIMPLEST defines many of the same attributes for both of these two schema entities (so that an instance of either schema entity will be appropriate for many purposes). Nonetheless, an SPML requester or provider that uses the SIMPLEST profile SHOULD clearly distinguish clearly between Person and Account.

The Organization schema entity is ubiquitous in directory services (and is therefore common in identity management systems). An instance of Organization usually represents a corporate entity—that is, a structured entity that consists of more than one person. The most common structure is a hierarchy: an instance of organization may contain any number of sub-organizations. Each organization (except the topmost) is contained by exactly one organization (its “parent”). (The topmost has no parent.) SIMPLEST represents these hierarchical relationships using the “parentOrg” and “childOrgs” attributes of Organization.

Persons are usually “leaf” nodes of an organizational hierarchy. In SIMPLEST an instance of Person may refer to an instance of Organization using the “ou” attribute (A.K.A. “memberOfOrganization”). (NOTE: SIMPLEST Organization could expose a “hasMember” attribute that would allow an organization to refer to each person that the organization contains. However, this approach tends to scale poorly because a “hasMembers” attribute may contain so many values. This approach also introduces a requirement to synchronize the “hasMembers” attribute with any inverse attribute such as “memberOfOrganization”. It's usually better simply to have each instance of Person refer to an instance of Organization.)

The Group schema entity also represents an entity that consists of more than one person. (A group need not contain persons, but typically does.) Classically (as derived from Unix groups) a group cannot contain other groups, but many modern systems and applications allow this. Thus, modern groups may form a hierarchical structure. (SIMPLEST allows group nesting using the “parentGroup” and “childGroups” attributes of Group.) The primary difference between Group and Organization is semantic: Group structure is assumed to be orthogonal to (i.e., a dimension independent of) any organizational hierarchy. The syntactic difference between Group and Organization is that, while a person should belong to at most one organization, a person may belong to any number of groups. (SIMPLEST allows a person to refer to any number of groups by means of the “groups” attribute of Person. This approach scales better than having a Group refer to each of its members—see the discussion of “hasMember” above in this same section.)

The Role schema entity represents something similar to a Group—a container for persons. Like Group, Roles may form a hierarchical structure. (SIMPLEST allows a role nesting using the “parentRole” and “childRoles” attributes of Role.) Also like Group, Role membership is not exclusive—a person may have more than one role. (The “roles” attribute of Person allows a person to refer to any number of roles. This approach scales better than having a Group refer to each of its members—see the discussion of “hasMember” above in this same section.) The semantic difference between Group and Role is that group membership is generally “shallow”--that is, group membership entails little or no data beyond the fact of membership. Role membership is usually “deeper”: a role may confer privileges including access to specific resources. (NOTE: Group and Role are sometimes conflated--much as Person and Account are sometimes conflated. SIMPLEST therefore defines the Group and Role schema entities with many of the same attributes. Nonetheless, an SPML requester or provider that uses the SIMPLEST profile SHOULD clearly distinguish clearly between Group and Role.)