Seeded repo with initial and secondary research

canon/CanonicalGlossary.md

@@ -0,0 +1,251 @@
+# Canonical Glossary
+
+Status: draft. These definitions are initial candidate canon terms. They are
+intended to be challenged by source-note backfill and scenario testing.
+
+## Actor
+
+An entity that can participate in relationships, hold or control accounts, be
+represented by another actor, or be projected into downstream systems.
+
+Includes: natural persons, organizations, communities, families, service
+accounts, bots, and AI agents.
+
+Excludes: raw identifiers, credentials, claims, and profiles unless they are
+being represented as records about an actor.
+
+## Natural Person
+
+A human being. A natural person may have many accounts, profiles, identifiers,
+credentials, personas, and relationships.
+
+Excludes: account records, social profiles, legal entities, and artificial
+agents.
+
+## Artificial Agent
+
+A non-human actor that performs actions under software, automation, or delegated
+control.
+
+Includes: bots, service agents, workloads, and AI agents.
+
+## Collective Actor
+
+An actor composed of or associated with multiple actors.
+
+Includes: organizations, communities, families, households, groups, and teams
+when they can participate in relationships or be represented.
+
+## Account
+
+An operational record in a scope that enables access, login, administration, or
+system participation.
+
+Includes: human login accounts and service accounts.
+
+Excludes: natural persons, billing accounts, profiles, credentials, and
+authorization principals unless a source uses account in that narrower context.
+
+## Service Account
+
+An account intended for software, workload, bot, or automation access rather
+than ordinary human interactive use.
+
+## Identity Record
+
+A record that describes, binds, or organizes information about an actor within
+a source or scope.
+
+Identity Record is deliberately narrower than bare `identity`; it is a record,
+not selfhood, not proof material, and not necessarily a login account.
+
+## Identifier
+
+A value or reference used to distinguish or refer to something within a scope.
+
+Examples: username, email address, LDAP DN, OIDC subject, SAML NameID, DID,
+employee number, external source ID.
+
+## Scoped Identifier
+
+An identifier whose meaning is intentionally limited to a relying party,
+sector, tenant, realm, application, namespace, or other scope.
+
+## Credential
+
+Evidence or secret material used to prove control, entitlement, or a claim.
+
+Examples: password, passkey, certificate, hardware token, verifiable
+credential, recovery code, signed assertion.
+
+## Claim
+
+A statement made by an issuer or source about an actor, account, identifier,
+relationship, or attribute.
+
+## Authenticated Subject
+
+The protocol-level representation of an entity after an issuer or identity
+provider identifies it for a relying party.
+
+Examples: OIDC subject, SAML subject.
+
+## Authorization Principal
+
+The entity considered by an authorization system when evaluating whether an
+action is allowed.
+
+## Profile
+
+A presentation or attribute surface for an actor or account in a scope.
+
+Examples: public social profile, local application profile, directory profile.
+
+## Persona
+
+A deliberate contextual presentation of an actor, often used to separate roles,
+audiences, privacy boundaries, or pseudonymous participation.
+
+## Scope
+
+A boundary within which identifiers, meanings, relationships, accounts,
+policies, or lifecycle states are valid.
+
+Examples: tenant, realm, relying party, namespace, application, community,
+authorization domain.
+
+## Tenant
+
+An administrative or isolation scope for a system, service, platform, or
+application.
+
+A tenant may be associated with an organization, customer, vendor, or community,
+but it is not automatically identical to any of them.
+
+## Realm
+
+An issuer, security, or administrative namespace used by an identity system.
+
+Candidate status: treat Realm as a Scope specialization unless source analysis
+shows it needs a separate canonical role.
+
+## Organization
+
+A collective actor with operational, social, administrative, or structural
+continuity.
+
+Excludes: tenant, customer, and legal entity unless those meanings are modeled
+as separate relationships or specializations.
+
+## Legal Entity
+
+An organization or other actor recognized by a legal system.
+
+## Customer
+
+An actor in a commercial or service-consumption relationship.
+
+Customer is a relationship role, not automatically a tenant or organization.
+
+## Vendor
+
+An actor in a service-provider relationship.
+
+Vendor is a relationship role, not automatically a tenant or organization.
+
+## Community
+
+A collective actor formed around participation, affiliation, identity, interest,
+moderation, or social interaction.
+
+## Family Or Household
+
+A collective actor or relationship network involving family, guardian,
+dependent, household, or care relationships.
+
+This concept is privacy-sensitive and may have legal implications outside the
+canon's scope.
+
+## Group
+
+A named collection of actors or accounts in a scope.
+
+Group membership may have authorization implications, but a group is not the
+same concept as a role, community, team, or organization.
+
+## Role
+
+A named capability bundle, responsibility, or relationship label within a
+scope.
+
+Roles may be assigned through memberships or relationships, but role is not
+identical to group.
+
+## Relationship
+
+A typed, scoped assertion connecting one actor, account, identifier, group, or
+other model element to another.
+
+Recommended fields: source, target, type, scope, evidence, issuer or source,
+confidence when relevant, lifecycle state, and authorization implications.
+
+## Membership Relationship
+
+A relationship indicating that an actor or account belongs to, participates in,
+or is accepted by a collective actor or scope.
+
+## Affiliation Relationship
+
+A relationship indicating association without necessarily implying membership,
+control, employment, or authorization.
+
+## Following Relationship
+
+A directed social relationship where one actor subscribes to, follows, or
+observes another actor or profile.
+
+## Representation Relationship
+
+A relationship where one actor acts or speaks on behalf of another actor within
+a scope.
+
+## Delegation Relationship
+
+A relationship where one actor grants bounded authority to another actor.
+
+## Administration Relationship
+
+A relationship where one actor has management authority over accounts,
+relationships, policies, or configuration in a scope.
+
+## Trust Relationship
+
+A relationship where one actor, issuer, verifier, system, or scope relies on
+another for claims, identifiers, credentials, or decisions.
+
+## Synonymity Assertion
+
+A scoped, evidenced assertion that two or more identifiers, records, accounts,
+profiles, or actors refer to the same target for a stated purpose.
+
+Synonymity assertions may be weak, strong, verified, inferred, revoked,
+privacy-limited, or source-specific.
+
+## Evidence Source
+
+A source, document, event, issuer, import, observation, or verification process
+supporting a claim, relationship, or synonymity assertion.
+
+## Lifecycle State
+
+The current state of a record, account, relationship, credential, claim, or
+assertion.
+
+Examples: proposed, active, suspended, revoked, expired, archived, deleted,
+superseded.
+
+## Non-Canonical Convenience Term: User
+
+`User` may be used in prose when quoting or mapping external systems, but it
+should not be a canonical root concept. Resolve it to a specific canonical
+concept before using it in model definitions.

canon/DesignPrinciples.md

@@ -0,0 +1,75 @@
+# Design Principles
+
+Status: draft. These principles make the proposal's modeling stance explicit.
+They are constraints for canonical vocabulary and conceptual model work, not
+implementation requirements for downstream systems.
+
+## P1. Use Actor As The Participation Root
+
+Do not start the model with `user`. An Actor is anything that can participate
+in relationships, hold accounts, be represented, or be evaluated by downstream
+systems. Natural persons, organizations, communities, families, and artificial
+agents can all be actors.
+
+## P2. Keep Person, Account, Identity, Profile, And Principal Separate
+
+A natural person is not an account. An account is not a profile. A profile is
+not a credential. A principal is an authorization projection. A subject is an
+issuer-bound protocol view. These distinctions prevent the most common identity
+model collapse.
+
+## P3. Treat Scope As First Class
+
+Identifiers, accounts, relationships, roles, policies, and meanings are only
+stable within a scope. A scope may be a tenant, realm, relying party, sector,
+community, application, namespace, or authorization domain.
+
+## P4. Model Collective Actors Without Collapsing Them
+
+Organizations, legal entities, customers, vendors, communities, families,
+households, groups, and teams are not interchangeable. They may relate to each
+other, but each should keep its social, legal, operational, or commercial
+meaning visible.
+
+## P5. Model Relationships Explicitly
+
+Membership, affiliation, following, ownership, representation, delegation,
+administration, employment, guardianship, and trust are separate relationship
+types. Do not hide them inside groups, roles, or ad hoc attributes.
+
+## P6. Keep Authorization Projections Separate
+
+Authorization engines need principals, resources, actions, roles, policies, and
+relationship tuples. These are projections from the conceptual identity model,
+not the whole identity model.
+
+## P7. Treat Synonymity As An Assertion
+
+Weak matches, verified links, same-as claims, and merges are different. The
+canon should represent synonymity as a scoped, evidenced, revocable assertion
+with confidence and method, never as an automatic destructive merge.
+
+## P8. Preserve Source And Evidence
+
+Source systems, issuers, import jobs, operators, documents, and verification
+events matter. Claims and relationships should be traceable to evidence or
+source references when the model depends on them.
+
+## P9. Prefer Orthogonal Concepts Over Product Terms
+
+External systems are mapping targets, not the source of canonical truth. If a
+product calls something a user, organization, group, project, tenant, or realm,
+the canon should identify the underlying concept before adopting the label.
+
+## P10. Test Concepts Against Scenarios
+
+Every canonical concept should survive concrete scenarios: enterprise
+directories, vendor/customer tenancy, families, communities, social graphs,
+service accounts, delegated agents, weak matches, strong links, and
+pseudonymous profiles.
+
+## P11. Keep Implementation Recommendations Downstream
+
+The repository may recommend downstream schemas, APIs, UI flows, or adapters,
+but it should not implement them directly. Implementation ideas belong in
+`DownstreamRecommendations.md` or a dedicated downstream workplan.