identity-canon/OpenQuestions.md

# Open Questions

Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Questions are
intentionally non-secret and implementation-neutral. Resolved items are noted
with corpus citations.

## Canon Questions

### Realm as Scope specialization

**Status:** Tentatively resolved — keep Realm as Scope specialization.

Keycloak source review (`research/identity-provisioning/keycloak-organizations.md`)
shows realm as hard identity/admin namespace, distinct from Organization B2B
overlay. Federation issuers (OIDC, SAML) also use issuer namespace semantics
compatible with Realm as Scope.

**Remaining nuance:** SaaS products calling Keycloak realms "tenants" need
explicit Organization + Tenant + Realm mapping in downstream adapters.

### Customer Account as canonical concept

**Status:** Resolved — do not add Customer Account; add Commercial Record instead.

**Decision:** Customer Account is not a canonical concept. The term overloads
login Account, billing customer (Stripe), CRM account (Salesforce), and B2B
subscriber organization (Auth0/Stytch).

**Canonical pattern:**

| Source label | Canonical mapping |
| --- | --- |
| B2B subscriber / customer org (Auth0, Stytch, ZITADEL) | Organization actor + Customer Relationship role + Tenant Scope |
| Login user / member | Account + Membership Relationship |
| Stripe Customer / CRM Account | Commercial Record (Record layer) |
| Individual subscriber (no company) | Natural Person + Tenant Scope + Commercial Record |

**New concepts added (not participation roots):**

- **Commercial Record** — Record layer entity for billing/commerce system records.
- **Commercial Relationship** — typed relationship linking vendor and customer
  actors, optionally referencing a Commercial Record.

**Convenience term only:** Subscriber (map like User — resolve before use).

**Citations:**

- `research/commercial-subscription/b2b-saas-subscriber-tenancy.md`
- `research/commercial-subscription/stripe-customer-billing.md`
- `research/identity-provisioning/keycloak-organizations.md`
- `research/identity-provisioning/zitadel-organizations-projects.md`

### Team modeling

**Status:** Open.

Schema.org and collaboration products use team for org units or project groups.
Corpus supports Team as Group or Organization Unit specialization depending on
whether the team has independent governance.

**Decision needed:** Default mapping rule when source does not distinguish team
from department.

### Legal Entity modeling

**Status:** Open — both patterns viable.

Schema.org treats Organization without mandatory legal status. Scenario S15
requires separation of Organization, Legal Entity, and Tenant. Corpus supports
Legal Entity as specialization when evidenced, or as relationship to legal
system.

**Decision needed:** Prefer specialization vs. relationship as default pattern.

### Mandatory Synonymity Assertion fields

**Status:** Open.

ResearchSeed and `synonymity-assertions.md` propose a field set. Corpus sources
agree on scope, evidence, strength, and lifecycle but differ on which fields
are universal vs. relationship-type-specific.

**Decision needed:** Minimum required fields for all assertions vs. sensitive
relationships (delegation, representation, synonymity).

## Synonymity Questions

### Confidence vocabulary

**Status:** Open — candidate bands defined.

Entity-resolution source (`deterministic-vs-probabilistic-matching.md`) and
synonymity model propose weak/medium/strong/authoritative. Probabilistic
literature uses continuous scores.

**Decision needed:** Standardize bands only, or also allow numeric score with
band mapping.

### Minimum evidence for strong links

**Status:** Partially resolved.

Corpus identifies authoritative deterministic keys per source family:

- OIDC `iss` + `sub` after RP verification
- SAML persistent NameID with SP policy
- Operator-verified account linking
- VC cryptographic proof with valid status

Weak-only: probabilistic scores, schema.org sameAs, shared email without
verification.

**Remaining:** Whether SCIM `externalId` alone is medium or weak strength.

### Revocation and cache effects

**Status:** Open (downstream-heavy).

SSF/RISC events (`shared-signals-caep-risc.md`) define issuer-side lifecycle
events. Canon should model assertion revocation; cache invalidation is
downstream.

### Privacy-limited link representation

**Status:** Partially resolved.

GDPR and OIDC pairwise sources support privacy classification on assertions
and separated re-identification keys. S14 scenario checks pass with
Persona + Scoped Identifier + privacy-limited Synonymity Assertion.

**Remaining:** Standard `privacy_classification` enum vs. policy reference.

## Corpus Questions

### Backfill priority

**Status:** Resolved.

IDENTITY-WP-0003 completed backfill in priority order: provisioning/federation
(9 notes), authorization/social (8 notes), verifiable claims/entity-resolution
(6 notes). Terminology and model artifacts refreshed from corpus.

### Product-specific detail placement

**Status:** Resolved.

Source notes capture product vocabulary and mapping implications. Implementation
patterns and adapter recommendations belong in `DownstreamRecommendations.md`.

### Citation format

**Status:** Resolved for this pass.

Source notes use:

- RFC/spec URL in References section
- Product documentation URL where applicable
- Source note filename as internal cross-reference

No separate bibliography file added.

## Commercial Identity Research (2026)

Deep research recorded under `research/commercial-identity/`. Key finding:
identity and commerce are coupled in practice through **commercial binding** —
evidenced obligations that raise counterparty reliance and make identity less fluid.

### Commercial Commitment placement

**Status:** Tentatively resolved — first-class Relationship-layer concept.

Contracts, subscriptions, payment mandates, and regulated onboarding acceptance
map to **Commercial Commitment** attached to Commercial Relationship or
Commercial Record. See `commercial-identity-synthesis.md`.

**Remaining:** Whether pipeline stages (CRM Opportunity) are commitments or
downstream-only.

### Beneficial Owner modeling

**Status:** Open.

KYC sources require natural persons behind legal entity customers. Candidate:
Beneficial Owner as Natural Person + Ownership/Representation with Evidence.

**Decision needed:** Dedicated relationship type vs. Ownership subtype with
`beneficial` role metadata.

### Reputation as canon concept

**Status:** Open — leaning toward Evidence Source aggregation.

Credit scores (PAYDEX), performance history, and repeat-play trust may not need
a separate Reputation entity if modeled as Evidence Source + Trust Relationship
with temporal scope.

### Registry identifier subtype

**Status:** Open.

LEI, DUNS, UEI, and company registration numbers share renewal, authority, and
cross-registry linking needs. Candidate: authoritative **Registry Identifier**
subtype with renewal Lifecycle State.

### Payment credential boundary

**Status:** Open (downstream-heavy).

Whether payment methods on Commercial Record map to Credential in canon or remain
PCI-scoped downstream artifacts only.

## New Questions From Corpus Review

### Cerbos derived roles vs. explicit relationships

Cerbos encodes ownership as derived roles from resource attributes. Should
canon actively discourage attribute-encoded ownership without backing Ownership
Relationship?

### ActivityPub cross-server actor linking

Should multiple ActivityPub actors for one Natural Person require explicit
Synonymity Assertion, or remain unlinked by default?

### Assurance dimension storage

Should IAL/AAL/FAL be stored as orthogonal fields on Account bindings, or as
metadata on Synonymity Assertion / Trust Relationship only?

### Kratos Identity unified vs. split

Should Kratos Identity map to unified Identity Record or split Account + Profile
in canonical adapters?