# 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:** Resolved — first-class concept with explicit promotion thresholds.

Contracts, subscriptions, payment mandates, purchase orders, and regulated
onboarding map to **Commercial Commitment**. CRM **Opportunity** maps to
**Pipeline Pursuit** — not commitment until `binding_trigger` (signed LOI/quote,
executed PO/contract, active subscription). Salesforce Forecast "Commit" is
pipeline metadata only.

**Citations:**

- `research/commercial-identity/crm-pipeline-commitment-threshold.md`
- `research/commercial-identity/commercial-identity-synthesis.md`

### Beneficial Owner modeling

**Status:** Resolved — **Beneficial Ownership Relationship** as dedicated type.

**Decision:** Model regulated beneficial ownership as **Beneficial Ownership
Relationship** from **Natural Person** to **Organization** / **Legal Entity**
customer. Use `ownership_prong`, `control_prong`, `equity_percentage`,
`control_basis`, and `intermediary_chain` metadata. Keep **Beneficial Owner** as
a glossary role label for the person, not a participation root.

**Rationale:** Distinct from corporate parent Ownership (LEI Level 2), operational
resource ownership (Cerbos), and Representation (authorized signers). FinCEN CDD
uses dual prongs with trust look-through; collapsing into Ownership subtype would
collide with authorization and corporate-structure semantics.

**Citations:**

- `research/commercial-identity/beneficial-ownership-kyc-boi.md`
- `research/commercial-identity/kyc-aml-commercial-identity-binding.md`

**Nuance settled:** `control_basis` enum and separate CDD vs. BOI filing layers.
See `commercial-identity-nuance-settlement.md`.

### Reputation as canon concept

**Status:** Resolved — tiered Evidence Source pattern; no Reputation entity.

**Decision:** Model reputation as a **Counterparty Assurance Gradient** across
four tiers — opinion (Reputation Signal), observed (Performance Evidence),
committed (Commercial Commitment), adjudicated (Adjudication Outcome). **Trust
Relationship** cites `assurance_basis`; do not equate star ratings with bonds or
court judgments.

**Rationale:** Star ratings are gamable and scope-local; PAYDEX and SLA metrics
are observed evidence; bonds and escrow are Commercial Commitments; arbitration
and courts produce Adjudication Outcomes. A single "reputation" root would collapse
enforceability and attribution differences.

**Citations:**

- `research/commercial-identity/reputation-assurance-gradient.md`
- `research/commercial-identity/commercial-trust-binding-theory.md`
- `research/commercial-identity/duns-commercial-credit-identity.md`

**Nuance settled:** Escrow → `commitment_type: escrow`; reputation portability
via weak `linked_to` Synonymity between Reputation Signals. See nuance settlement note.

### Registry identifier subtype

**Status:** Resolved — **Registry Identifier** subtype with authority classes.

**Decision:** Add **Registry Identifier** as an Identifier specialization in the
Reference layer. Encode scheme via ISO/IEC 6523 ICD where applicable. Use
`authority_class` (`government_registry`, `regulatory_global`, `commercial_proxy`,
`tax`), `renewal_required`, and `lifecycle_state` (esp. LEI annual renewal).
Add **Proxy Commercial Identifier** for vendor-operated keys (DUNS, ICD 0060).
Link multiple registry IDs for one entity via **Synonymity Assertion**.

**Citations:**

- `research/commercial-identity/registry-identifier-subtypes.md`
- `research/commercial-identity/lei-gleif-legal-entity-identifier.md`
- `research/commercial-identity/duns-commercial-credit-identity.md`

**Nuance settled:** Cross-registry Synonymity strength table; OPI → Organization
Unit / branch Registry Identifier. See nuance settlement note.

### Payment credential boundary

**Status:** Resolved — Payment Instrument Reference + Payment Mandate; not Credential.

**Decision:** Do not map payment methods to **Credential**. CHD (PAN, CVV) is
out of canon (PCI downstream). Tokenized provider references (`pm_xxx`) map to
**Payment Instrument Reference** on **Commercial Record**. Customer authorization
to charge maps to **Payment Mandate** (**Commercial Commitment**,
`commitment_type: payment_mandate`). Login credentials remain separate.

**Citations:**

- `research/commercial-identity/payment-credential-pci-boundary.md`
- `research/commercial-subscription/stripe-customer-billing.md`

**Nuance settled:** Network tokens, shared instrument refs, wallet balance as
Commercial Record attribute. See `commercial-identity-nuance-settlement.md`.

### Commercial identity nuance settlement (2026)

**Status:** Resolved — consolidated in `commercial-identity-nuance-settlement.md`.

Covers: `control_basis` and BOI/CDD layering; registry crosswalk strengths;
OPI branch modeling; assurance tier vs. numeric score; escrow commitment type;
reputation portability; oracle vs. adjudicated outcomes; `binding_trigger` enum;
renewal amendment vs. new pursuit; Person Account adapter projection; eIDAS seal
and EUDI wallet Scope.

## 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?