tegwick
6ea582cd9e
Add research on PCI/tokenized payment references vs login Credentials (Payment Instrument Reference, Payment Mandate) and CRM Opportunity promotion thresholds (Pipeline Pursuit, binding_trigger). Resolve OpenQuestions for both topics. Update glossary, conceptual model, terminology, and downstream recommendations.
11 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: 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.mdresearch/commercial-subscription/stripe-customer-billing.mdresearch/identity-provisioning/keycloak-organizations.mdresearch/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+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.
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.mdresearch/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.mdresearch/commercial-identity/kyc-aml-commercial-identity-binding.md
Remaining nuance: Standard control_basis enum across jurisdictions; BOI
reporting volatility vs. enduring CDD collection obligations.
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.mdresearch/commercial-identity/commercial-trust-binding-theory.mdresearch/commercial-identity/duns-commercial-credit-identity.md
Remaining nuance: Whether segregated platform escrow is committed without a
separate contract artifact; cross-platform reputation portability via Synonymity.
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.mdresearch/commercial-identity/lei-gleif-legal-entity-identifier.mdresearch/commercial-identity/duns-commercial-credit-identity.md
Remaining nuance: Synonymity strength bands for LEI ↔ DUNS crosswalks; branch OPI modeling under ISO 6523.
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.mdresearch/commercial-subscription/stripe-customer-billing.md
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?