Archived

This repository has been archived on 2026-07-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

tegwick 1c1b5c9bc6 Complete IDENTITY-WP-0003 corpus backfill and model refinement

Backfill all 23 research source notes with terminology extracts, modeling
assumptions, conflicts, canonical mappings, and references. Refresh terminology
artifacts, refine the conceptual model with explicit scenario paths, reconcile
canon surfaces and open questions, and mark the workplan finished.

2026-06-21 20:22:20 +02:00

5.9 KiB

Raw Blame History

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

5.9 KiB Raw Blame History