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.

OpenQuestions.md

@@ -1,35 +1,163 @@
 # Open Questions
 
-Status: draft. These questions are intentionally non-secret and
-implementation-neutral.
+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
 
-- Should Realm stay a Scope specialization, or does it need its own canonical
-  concept because of issuer and federation semantics?
-- Should Customer Account become a canonical concept, or should customer
-  account records remain downstream commercial modeling?
-- Should Team be modeled as a Group, Organization Unit, Community, or a
-  separate specialization?
-- Should Legal Entity be a specialization of Organization or a relationship
-  between an Organization and a legal system?
-- What fields are mandatory for every Relationship versus only for sensitive
-  relationships such as delegation, representation, and synonymity?
+### 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:** Open — leaning toward Organization + Customer role.
+
+ZITADEL and Keycloak model customer-like boundaries as Organization with tenant
+semantics, not a separate account type. No corpus source defines Customer
+Account as distinct from Organization actor + Customer relationship role +
+Tenant scope.
+
+**Decision needed:** Whether billing/commercial account records warrant a
+downstream-only model or a canonical Customer Account specialization.
+
+### 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
 
-- Which confidence vocabulary should be used for weak matches?
-- What is the minimum evidence model for strong account links?
-- How should revocation or expiry of a synonymity assertion affect downstream
-  caches?
-- How should privacy-limited links be represented so accidental broadening is
-  visible during review?
+### 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
 
-- Which source notes should be backfilled first: SCIM and LDAP for record
-  semantics, OIDC and SAML for subject semantics, or OpenFGA and Cedar for
-  authorization projections?
-- How much product-specific detail belongs in source notes versus downstream
-  recommendations?
-- What citation format should the repo use once source notes are populated?
+### 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.
+
+## 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?