SIMPLEST schema entities and relationships.

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.)