generated from coulomb/repo-seed
tegwick
3ccf841095
Record B2B SaaS subscriber tenancy and Stripe billing source notes. Resolve the Customer Account open question: reject it as canonical, add Commercial Record and Commercial Relationship to the Record and relationship layers, and document Subscriber as a convenience term only.
183 lines
6.1 KiB
Markdown
183 lines
6.1 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:** 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.
|
|
|
|
## 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? |