Distribute frozen federation corpus by concept destination
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
3e3191549a
commit
372f671eef
81 changed files with 14146 additions and 99 deletions
|
|
@ -0,0 +1,230 @@
|
|||
# Terminology Conflict Map
|
||||
|
||||
Status: draft. Revised after IDENTITY-WP-0003 corpus backfill. Each conflict
|
||||
includes source-backed examples from populated research notes.
|
||||
|
||||
## Conflict: User
|
||||
|
||||
Problem: `user` can mean a person, account, login credential holder,
|
||||
application profile, authorization subject, or product-facing actor.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
|
||||
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
|
||||
`zitadel-organizations-projects.md`)
|
||||
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
|
||||
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)
|
||||
|
||||
Canonical stance: do not use `user` as a root concept.
|
||||
|
||||
Current mapping rule:
|
||||
|
||||
- Provisioning record (SCIM/LDAP) → Identity Record
|
||||
- Login-enabled product record → Account
|
||||
- Public/local display → Profile
|
||||
- Access evaluation → Principal or Authenticated Subject
|
||||
- Human being → Natural Person
|
||||
|
||||
## Conflict: Identity
|
||||
|
||||
Problem: `identity` can mean selfhood, a directory record, an issuer-bound
|
||||
subject, a set of claims, a DID, a credential, a profile, or an account.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Kratos Identity = traits + credentials (`ory-kratos-keto.md`)
|
||||
- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`)
|
||||
- DID is identifier, not identity record (`did-core.md`)
|
||||
- VC credentialSubject = claims about subject (`vc-data-model-2.md`)
|
||||
|
||||
Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
|
||||
Claim, Credential, Profile, Persona, or Synonymity Assertion.
|
||||
|
||||
## Conflict: Account
|
||||
|
||||
Problem: account can mean login account, customer billing account, social
|
||||
media handle, service account, or FOAF online presence.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
|
||||
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
|
||||
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
|
||||
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)
|
||||
|
||||
Canonical stance: Account is operational access record in a scope. Billing
|
||||
records map to Commercial Record; commercial parties use Customer/Vendor roles
|
||||
and Commercial Relationship.
|
||||
|
||||
## Conflict: Subject, Principal, Actor
|
||||
|
||||
Problem: protocols, authorization engines, and social models overload these terms.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
|
||||
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
|
||||
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
|
||||
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
|
||||
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
|
||||
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
|
||||
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Actor = conceptual participant
|
||||
- Authenticated Subject = issuer/protocol view
|
||||
- Authorization Principal = decision-engine projection
|
||||
|
||||
## Conflict: Tenant, Realm, Organization, Customer
|
||||
|
||||
Problem: multi-tenant products collapse isolation boundaries and commercial actors.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
|
||||
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
|
||||
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
|
||||
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Tenant = administrative/isolation scope
|
||||
- Realm = issuer/admin namespace (Scope specialization)
|
||||
- Organization = collective actor
|
||||
- Customer = commercial relationship role
|
||||
|
||||
Model relationships among them; do not synonymize.
|
||||
|
||||
## Conflict: Group, Role, Team, Community
|
||||
|
||||
Problem: IAM groups, collaboration teams, social communities, and authz member
|
||||
relations use overlapping labels.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes)
|
||||
- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`)
|
||||
- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`)
|
||||
- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`)
|
||||
- Schema.org Organization subtypes include SportsTeam (`schema-org` note)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Group = named collection with membership
|
||||
- Role = capability bundle or relationship label
|
||||
- Team = collaboration group or org unit
|
||||
- Community = participation-oriented collective actor
|
||||
|
||||
## Conflict: Member, Follower, Affiliate
|
||||
|
||||
Problem: membership, following, affiliation, and authz member relations hide
|
||||
distinct semantics behind `member`.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`)
|
||||
- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`)
|
||||
- OpenFGA organization#member = authz projection (`openfga-modeling.md`)
|
||||
- FOAF member = group membership; knows = acquaintance (`foaf` note)
|
||||
|
||||
Canonical stance: use typed relationships with scope and evidence.
|
||||
|
||||
## Conflict: Profile And Persona
|
||||
|
||||
Problem: profiles are account records, RDF documents, public pages, or VC subjects.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- WebID profile document = RDF at URI (`webid-solid-profile.md`)
|
||||
- Kratos traits often called profile informally (`ory-kratos-keto.md`)
|
||||
- ActivityPub actor profile = public actor representation
|
||||
- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes)
|
||||
|
||||
Canonical stance:
|
||||
|
||||
- Profile = presentation surface in scope
|
||||
- Persona = deliberate contextual presentation with privacy boundaries
|
||||
|
||||
## Conflict: Identifier, Credential, Claim
|
||||
|
||||
Problem: tokens and documents bundle all three.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`)
|
||||
- VC = signed claims with proof (`vc-data-model-2.md`)
|
||||
- DID verification method = cryptographic credential (`did-core.md`)
|
||||
- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`)
|
||||
|
||||
Canonical stance: identifier refers; credential proves; claim states.
|
||||
|
||||
## Conflict: Synonymity, Linking, Matching, Merge
|
||||
|
||||
Problem: systems collapse probabilistic matches, verified links, and destructive
|
||||
merges into one feature.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
|
||||
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
|
||||
- Schema.org sameAs = weak web equivalence (`schema-org` note)
|
||||
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
|
||||
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
|
||||
|
||||
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
|
||||
|
||||
## Conflict: Credential (Auth) vs. Verifiable Credential
|
||||
|
||||
Problem: "credential" means password, OIDC token, or W3C VC.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- NIST authenticator/credential (`nist-800-63-4.md`)
|
||||
- VC Data Model verifiable credential (`vc-data-model-2.md`)
|
||||
- OpenID4VC bridges OAuth credential terminology with VCs (`openid4vc.md`)
|
||||
|
||||
Canonical stance: use Credential with context. VC maps to Credential containing
|
||||
Claims; login secrets map to Credential (authentication factor).
|
||||
|
||||
## Conflict: Issuer
|
||||
|
||||
Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
|
||||
- VC issuer signs credential (`vc-data-model-2.md`)
|
||||
- NIST CSP performs proofing (`nist-800-63-4.md`)
|
||||
|
||||
Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
|
||||
role when mapping.
|
||||
|
||||
## Conflict: Customer Account
|
||||
|
||||
Problem: `customer account` collapses login account, B2B subscriber organization,
|
||||
Stripe billing customer, and CRM account into one product noun.
|
||||
|
||||
Source evidence:
|
||||
|
||||
- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
|
||||
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
|
||||
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)
|
||||
|
||||
Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:
|
||||
|
||||
- login/access → Account;
|
||||
- subscribing company → Organization + Customer role + Tenant;
|
||||
- billing/CRM → Commercial Record;
|
||||
- vendor↔customer link → Commercial Relationship.
|
||||
|
||||
## Review Queue
|
||||
|
||||
- [x] Customer Account — resolved; use Commercial Record + Commercial Relationship.
|
||||
- [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope
|
||||
specialization; promote in glossary if scenario review confirms.
|
||||
- [ ] Split authz `member` relation from social Membership in downstream adapters.
|
||||
- [ ] Classify schema.org sameAs default strength — corpus says weak only.
|
||||
- [ ] Standardize assurance dimensions — NIST IAL/AAL/FAL as orthogonal metadata.
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
# Terminology Inventory
|
||||
|
||||
Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Mappings remain
|
||||
candidate until reviewed against `canon/CanonicalGlossary.md` and scenario
|
||||
tests.
|
||||
|
||||
## Use
|
||||
|
||||
Use this file to collect source terms and their current candidate canonical
|
||||
home. Use `terminology/TerminologyConflictMap.md` when a term is overloaded or
|
||||
has incompatible meanings across source families.
|
||||
|
||||
## Inventory
|
||||
|
||||
| Term | Candidate canonical concept | Source families | Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. |
|
||||
| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. |
|
||||
| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. |
|
||||
| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. |
|
||||
| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. |
|
||||
| identifier | Identifier | OIDC sub, SAML NameID, LDAP DN, DID, WebID | Value referring within or across scopes. See Scoped Identifier when correlation is limited. |
|
||||
| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. |
|
||||
| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. |
|
||||
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
|
||||
| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. |
|
||||
| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. |
|
||||
| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. |
|
||||
| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. |
|
||||
| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. |
|
||||
| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. |
|
||||
| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. |
|
||||
| machine user | Service Account | ZITADEL | Product term for non-human org identity. |
|
||||
| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. |
|
||||
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
|
||||
| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. |
|
||||
| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
|
||||
| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
|
||||
| stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. |
|
||||
| payment method / pm_xxx | Payment Instrument Reference | Stripe, Adyen | Tokenized provider reference; not Credential; not CHD in canon. |
|
||||
| payment mandate / setup intent | Payment Mandate (Commercial Commitment) | Stripe, SEPA | Authorization to charge; commitment_type payment_mandate. |
|
||||
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
|
||||
| opportunity (crm) | Pipeline Pursuit | Salesforce, HubSpot | In-flight deal; not Commercial Commitment until binding trigger. |
|
||||
| forecast commit (salesforce) | Pipeline Pursuit metadata | Salesforce | Sales forecast category; not Commercial Commitment. |
|
||||
| closed won | Pipeline Pursuit lifecycle + optional commitment | CRM | Won stage alone does not auto-create active commitment. |
|
||||
| quote accepted / loi signed | Commercial Commitment (proposed) | CPQ, sales | Binding trigger with document evidence. |
|
||||
| crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. |
|
||||
| customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. |
|
||||
| commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. |
|
||||
| commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. |
|
||||
| commercial commitment | Commercial Commitment | contracts, subscriptions, KYC | Binding obligation raising identity stakes. |
|
||||
| beneficial owner | Beneficial Owner + Beneficial Ownership Relationship | KYC/AML, FinCEN CDD, FATF R24 | Natural person behind legal entity customer; dedicated relationship type with ownership/control prongs. |
|
||||
| beneficial ownership | Beneficial Ownership Relationship | FinCEN CDD, BOI, Open Ownership | Regulated Natural Person → Organization/Legal Entity linkage; not Ownership subtype. |
|
||||
| lei | Registry Identifier (regulatory_global) | GLEIF, ISO 17442, ICD 0199 | Legal entity identifier with annual renewal. |
|
||||
| duns | Proxy Commercial Identifier | D&B, ICD 0060 | Commercial-proxy registry identifier. |
|
||||
| uei | Registry Identifier (government_registry) | SAM.gov | US federal entity identifier. |
|
||||
| company registration number | Registry Identifier (government_registry) | national registers, ALEI | Authoritative incorporating-register identifier. |
|
||||
| alei / ibrn | Registry Identifier (government_registry) | ISO 8000-116 | Authoritative legal entity identifier from government register. |
|
||||
| iso 6523 / icd | Registry Identifier scheme | ISO/IEC 6523, PEPPOL | ICD + organization identifier encoding. |
|
||||
| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
|
||||
| paydex | Performance Evidence | D&B | Observed-tier payment performance metric. |
|
||||
| reputation | Resolve by assurance tier | marketplaces, credit | Not canonical — see Counterparty Assurance Gradient. |
|
||||
| star rating / review | Reputation Signal | Yelp, Amazon, App Store | Opinion-tier Evidence Source; weak, gamable. |
|
||||
| feedback score | Reputation Signal | eBay, Uber | Platform-local opinion tier. |
|
||||
| credit score | Performance Evidence | bureaus, D&B | Observed-tier counterparty metric. |
|
||||
| performance bond / surety | Commercial Commitment | construction, procurement | Committed-tier financial assurance. |
|
||||
| escrow | Commercial Commitment | marketplaces, Stripe | Committed-tier funds segregation. |
|
||||
| arbitration award | Adjudication Outcome | AAA, ICC, JAMS | Adjudicated-tier dispute result. |
|
||||
| court judgment | Adjudication Outcome | courts | Adjudicated-tier enforcement outcome. |
|
||||
| assurance gradient | Counterparty Assurance Gradient | commercial identity | Four-tier reliance model (opinion → adjudicated). |
|
||||
| control_basis | Beneficial Ownership Relationship metadata | FinCEN CDD, EU AMLD | Settled role enum (chief_executive, managing_member, …). |
|
||||
| binding_trigger | Pipeline Pursuit promotion | CRM adapters | Settled enum (quote_accepted, contract_executed, …). |
|
||||
| fincen id | Registry Identifier (government_registry) | BOI | Natural person government registry ID. |
|
||||
| person account | Natural Person + Commercial Record | Salesforce B2C | Adapter projection_mode person_account_combined only. |
|
||||
| ncage / cage | Registry Identifier (industry_association) | defense procurement | Industry association authority class. |
|
||||
| network token | Payment Instrument Reference | Visa VTS, MDES | instrument_type network_token. |
|
||||
| escrow (platform) | Commercial Commitment (escrow) | marketplaces | Committed tier when funds segregated. |
|
||||
| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. |
|
||||
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
|
||||
| fluid identity | Persona / weak binding | theory | Low commercial stake; intentional mutability. |
|
||||
| bound identity | Commercial Commitment present | theory | High counterparty reliance; stable identifiers. |
|
||||
| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. |
|
||||
| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. |
|
||||
| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. |
|
||||
| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. |
|
||||
| instance | Scope | ZITADEL | Deployment-level boundary above organizations. |
|
||||
| project | Application Scope | ZITADEL | Application/product container within org. |
|
||||
| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. |
|
||||
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
|
||||
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
|
||||
| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. |
|
||||
| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. |
|
||||
| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. |
|
||||
| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. |
|
||||
| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. |
|
||||
| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. |
|
||||
| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. |
|
||||
| follow | Following Relationship | ActivityPub | Activity establishing follower edge. |
|
||||
| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. |
|
||||
| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. |
|
||||
| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. |
|
||||
| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. |
|
||||
| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. |
|
||||
| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. |
|
||||
| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. |
|
||||
| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. |
|
||||
| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. |
|
||||
| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. |
|
||||
| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. |
|
||||
| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. |
|
||||
| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. |
|
||||
| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. |
|
||||
| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. |
|
||||
| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. |
|
||||
| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. |
|
||||
| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. |
|
||||
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
|
||||
| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. |
|
||||
| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. |
|
||||
| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. |
|
||||
| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. |
|
||||
| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. |
|
||||
| distinguished name | Identifier | LDAP | Compound locator in directory namespace. |
|
||||
| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. |
|
||||
| traits | Profile attributes | Kratos | Schema-validated identity attributes. |
|
||||
| verification method | Credential | DID Core | Cryptographic key in DID document. |
|
||||
| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. |
|
||||
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
|
||||
| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. |
|
||||
| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. |
|
||||
| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. |
|
||||
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
|
||||
| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. |
|
||||
| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. |
|
||||
| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. |
|
||||
| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. |
|
||||
| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. |
|
||||
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
|
||||
| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. |
|
||||
| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. |
|
||||
| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. |
|
||||
|
||||
## Source Note Citations
|
||||
|
||||
Terms above are grounded in backfilled notes under:
|
||||
|
||||
- `research/identity-provisioning/` (5 notes)
|
||||
- `research/authentication-federation/` (4 notes)
|
||||
- `research/authorization-relationships/` (4 notes)
|
||||
- `research/social-community-graphs/` (4 notes)
|
||||
- `research/verifiable-claims/` (3 notes)
|
||||
- `research/entity-resolution-privacy/` (3 notes)
|
||||
- `research/commercial-subscription/` (2 notes)
|
||||
- `research/commercial-identity/` (8 notes)
|
||||
|
||||
## Remaining Backfill Needs
|
||||
|
||||
- Split `group` into authorization group vs. social collective where sources
|
||||
disagree (OpenFGA member vs. ActivityPub follower).
|
||||
- Add product-version qualifiers when Keycloak/ZITADEL models evolve.
|
||||
- Promote stable mappings to `canon/CanonicalGlossary.md` after scenario
|
||||
review.
|
||||
Loading…
Add table
Add a link
Reference in a new issue