tegwick
1c1b5c9bc6
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.
5.2 KiB
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: 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
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+subafter 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.
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?