generated from coulomb/repo-seed
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.
163 lines
5.2 KiB
Markdown
163 lines
5.2 KiB
Markdown
# 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` + `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.
|
|
|
|
## 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? |