commerce-canon/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md

# LDAP RFC 4519 and inetOrgPerson RFC 2798

## Source Type

Standard. RFC 4519 defines LDAP attribute types and object classes; RFC 2798
defines the `inetOrgPerson` auxiliary object class for Internet person entries.

## Domain

Directory services, enterprise identity records, and hierarchical naming.

## Why This Source Matters

LDAP directory schema, RFC 4519 attribute/object class vocabulary, and
inetOrgPerson RFC 2798.

LDAP remains the structural backbone of many enterprise directories. Its
distinguished names, organizational units, and groupOfNames semantics
precede and often underpin SCIM and IAM product models.

## Key Concepts

- **Directory Information Tree (DIT)**: hierarchical namespace of entries
  identified by Distinguished Names (DNs).
- **Entry**: a collection of attribute type/value pairs with one structural
  object class and optional auxiliary object classes.
- **Distinguished Name (DN)**: unique identifier within a directory; composed
  of Relative Distinguished Names (RDNs) such as `cn`, `ou`, `dc`.
- **inetOrgPerson**: auxiliary object class for person entries with `cn`,
  `sn`, `mail`, `uid`, `employeeNumber`, and related attributes.
- **organizationalUnit (ou)**: container for organizational structure.
- **groupOfNames / groupOfUniqueNames**: group entries with `member` or
  `uniqueMember` attributes referencing member DNs.
- **posixAccount / posixGroup**: UNIX-oriented account and group semantics
  with `uid`, `gid`, `homeDirectory`, and `memberUid`.
- **Attribute syntax and matching rules**: typed attributes (DirectoryString,
  IA5String, JPEG) with defined comparison semantics.
- **Referrals and aliases**: indirection for distributed or aliased entries.

## Relevant Terminology

| Term | Source meaning |
| --- | --- |
| person / inetOrgPerson | Directory entry representing a human; attributes, not a login session. |
| uid | User identifier string; often login name in POSIX contexts. |
| cn (commonName) | Display or legal name component of DN. |
| mail | Email address attribute; may be multi-valued. |
| employeeNumber | Workforce identifier assigned by employer. |
| ou (organizationalUnit) | Structural container in the DIT; department or division. |
| dc (domainComponent) | DNS-domain component in DN; defines directory partition. |
| member / uniqueMember | DN reference from a group entry to a member entry. |
| groupOfNames | Group requiring at least one member; membership by DN reference. |
| account (posixAccount) | UNIX account attributes bound to a person entry. |

## Modeling Assumptions

- **Identity is entry-centric**: a person is a directory entry located in a
  hierarchical tree, not a free-floating actor.
- **Naming implies structure**: DN path encodes organizational placement
  (`ou=Engineering,ou=People,dc=example,dc=com`).
- **Groups are entries**, not relationships; membership is an attribute on the
  group entry pointing to member DNs.
- **Person and account can co-reside** on one entry (inetOrgPerson +
  posixAccount auxiliary class).
- **Uniqueness** is per-directory-partition; `uid` or DN must be unique within
  scope.
- **No standard org-entity object class** for corporations; org structure is
  implied by `ou` containers.
- **Authorization** is external; groups are conventionally mapped to permission
  sets by consuming applications.

## Identity-Canon Implications

- LDAP **inetOrgPerson entry** maps to **Identity Record** with optional
  **Account** when posixAccount or login-binding attributes are present.
- **DN** and **uid** are **Identifiers** within the directory **Scope**
  (namespace).
- **organizationalUnit** maps to a structural container, candidate
  **Organization Unit** or scope partition — not automatically an
  **Organization** actor.
- **groupOfNames** maps to **Group** with **Membership Relationship** via
  member DN references.
- DN hierarchy suggests **Affiliation** or structural relationships but LDAP
  does not type them explicitly.
- LDAP reinforces that **Identifier** (DN) carries locational semantics
  beyond bare value identity.

## Terminology Conflicts

- **Account**: posixAccount is attribute bundle on a person entry; conflicts
  with IAM Account as a distinct operational record.
- **User**: directory "user" means entry or uid; conflicts with application
  session user.
- **Organization**: `ou` is a container, not a legal or commercial org actor.
- **Group**: LDAP group is an entry with member attributes; conflicts with
  SCIM Group resource and social community.
- **Person**: inetOrgPerson is a schema label, not a legal natural-person
  assertion.

## Candidate Canonical Mappings

| LDAP concept | Candidate canonical concept |
| --- | --- |
| inetOrgPerson entry | Identity Record |
| posixAccount attributes | Account (co-located on same entry) |
| DN | Identifier (locator + namespace) |
| uid, mail, employeeNumber | Identifier |
| organizationalUnit (ou) | Scope partition or org-unit container |
| groupOfNames entry | Group |
| member / uniqueMember | Membership Relationship |
| dc partition | Scope / Namespace |
| attribute values | Profile attributes or Claims on Identity Record |

## Open Questions

- Should DN be modeled as a compound Identifier (locator + value) or split
  into Namespace Scope plus local Identifier?
- How should multi-valued `mail` attributes interact with synonymity assertions
  when matching across systems?
- Does `ou` hierarchy warrant a canonical **Organizational Structure**
  relationship type, or remain a naming convention?
- When inetOrgPerson and posixAccount coexist, is one Identity Record with
  Account facet sufficient?

## References

- RFC 4519: LDAP Attribute Types and Object Classes — https://datatracker.ietf.org/doc/html/rfc4519
- RFC 2798: Definition of the inetOrgPerson Object Class — https://datatracker.ietf.org/doc/html/rfc2798
- RFC 4511: LDAP Protocol — https://datatracker.ietf.org/doc/html/rfc4511
- RFC 2307: POSIX account/group schema — https://datatracker.ietf.org/doc/html/rfc2307