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.
This commit is contained in:
2026-06-21 20:22:20 +02:00
parent 790a2f2041
commit 1c1b5c9bc6
32 changed files with 2676 additions and 623 deletions

View File

@@ -1,50 +1,130 @@
# Ldap Rfc4519 Inetorgperson Rfc2798
# LDAP RFC 4519 and inetOrgPerson RFC 2798
## Source Type
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
Standard. RFC 4519 defines LDAP attribute types and object classes; RFC 2798
defines the `inetOrgPerson` auxiliary object class for Internet person entries.
## Domain
TODO: Classify the source 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 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
TODO:
- concept 1
- concept 2
- concept 3
- **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
TODO: Extract terms used by the source and note their source-specific meaning.
| 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
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
- **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
TODO: Explain what this source suggests for the canonical identity model.
- 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
TODO: Record where this source uses terms differently from other sources.
- **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
TODO: Map source-specific concepts to identity-canon candidate concepts.
| 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
TODO:
- Question 1
- Question 2
- 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
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
- 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