Resolve payment credential and CRM pipeline commitment boundaries

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.

research/commercial-identity/payment-credential-pci-boundary.md

@@ -0,0 +1,167 @@
+# Payment Credential Boundary — PCI and Commercial Commitment
+
+## Source Type
+
+Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment
+Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment
+separation.
+
+## Domain
+
+Payment instruments on billing customers — what belongs in canonical identity
+model vs. PCI-scoped downstream vaults, and how charge authorization relates to
+Commercial Commitment.
+
+## Why This Source Matters
+
+Stripe **Customer** objects carry **payment methods**, and canon **Credential**
+already covers secrets and proof material. Collapsing them causes two failures:
+
+1. **PCI scope bleed** — modeling PAN, CVV, or vault secrets in identity canon
+   implies they belong in general identity stores.
+2. **Semantic collision** — login passkeys and payment mandates both "authorize
+   something" but authorize **authentication** vs. **commercial debit**.
+
+Payment methods are commercially binding (tier 3 assurance) when they encode
+**mandate to charge** — but the binding artifact is the **authorization/commitment**,
+not the token reference.
+
+## Key Concepts
+
+### PCI DSS data categories
+
+- **CHD (cardholder data)**: PAN, cardholder name, expiration, service code.
+- **Sensitive authentication data (SAD)**: CVV/CVC, full track data, PIN — never
+  stored after authorization per PCI.
+- **Token**: surrogate value replacing PAN; if properly implemented, token in
+  merchant environment is **out of PCI CHD scope** (PCI tokenization guidelines).
+- **Scope principle**: systems that store, process, or transmit CHD fall under PCI;
+  token references (`pm_xxx`) in app DBs are not CHD when only the token exists.
+
+### Stripe payment object model
+
+- **PaymentMethod** (`pm_xxx`): reusable payment details attached to Customer;
+  contains type-specific non-transaction data (last4, fingerprint, billing details).
+- **SetupIntent**: establishes future off-session payment — creates mandate to charge.
+- **PaymentIntent**: one-time or reusable charge attempt.
+- **Customer**: billing container; payment methods attach here, not to login User.
+- **Mandates** (SEPA, Bacs, etc.): explicit customer authorization for debits.
+
+### Authentication vs. payment authorization
+
+| Dimension | Authentication credential | Payment authorization |
+| --- | --- | --- |
+| Proves | Identity / session control | Right to debit funds |
+| Scope | IdP, app login, federation | Payment network / acquirer |
+| Regulation | NIST 800-63, OIDC | PCI DSS, PSD2 SCA, Nacha |
+| Canon home | Credential | Payment Mandate (Commercial Commitment) |
+| Secret handling | Passkey, password hash | CHD in vault only; token ref in app |
+
+## Modeling Assumptions
+
+- **Canon is implementation-neutral** but must not encourage CHD in identity layers.
+- **Payment provider owns payment truth**; app holds references and commitment state.
+- **Reusable payment method** implies **Commercial Commitment** (payment mandate)
+  when customer consented to future charges (SetupIntent succeeded, card on file).
+- **Single-use payment methods** may exist only for one PaymentIntent — weaker
+  commitment, often no reusable mandate.
+- **Subscription** is separate Commercial Commitment (recurring service obligation);
+  payment mandate is **enabling** commitment for collection.
+- **Webhook events** (`setup_intent.succeeded`, `payment_method.attached`) are
+  **Evidence Source** for mandate lifecycle.
+
+## Identity-Canon Implications
+
+### Resolved: do not map payment methods to Credential
+
+**Credential** in canon covers authentication, federation, and entitlement proof
+(passkey, password, certificate, VC). **Payment methods are not Credentials.**
+
+Raw CHD and SAD are **out of canon entirely** — downstream PCI vault / payment
+provider only.
+
+### Payment Instrument Reference
+
+Add **Payment Instrument Reference** — Reference layer value scoped to a payment
+provider (Stripe `pm_xxx`, fingerprint, display last4, mandate ID). Links to
+**Commercial Record**, not to login **Account**.
+
+Properties:
+
+- `provider_scope` — Stripe account, Adyen merchant, etc.
+- `instrument_type` — card, sepa_debit, us_bank_account, etc.
+- `reference_id` — provider token (not PAN).
+- `reusable` — boolean.
+- `lifecycle_state` — attached, detached, expired, revoked.
+
+This is a **Scoped Identifier** specialization, not a Credential.
+
+### Payment Mandate as Commercial Commitment
+
+When a customer authorizes future charges (SetupIntent success, SEPA mandate
+signed, card saved with explicit consent), model **Payment Mandate** as a
+**Commercial Commitment** subtype:
+
+- `commitment_type: payment_mandate`
+- `lifecycle_state`: proposed → active → revoked → expired
+- Parties: customer actor (via Commercial Record) and vendor/payment facilitator
+- **Evidence Source**: SetupIntent result, mandate document, SCA proof metadata
+- `assurance_tier: committed` on Counterparty Assurance Gradient
+
+**Subscription** remains `commitment_type: subscription` — distinct but often
+co-created at checkout.
+
+### Commercial Record role
+
+**Commercial Record** (Stripe Customer) **references** payment instrument refs
+and **hosts** links to Payment Mandate commitments. Do not embed CHD attributes
+in Commercial Record canon fields — only provider references and lifecycle flags
+(`delinquent`, default payment method ref).
+
+### Layer diagram
+
+```text
+Login Account          → Credential (passkey, password)
+Commercial Record      → Payment Instrument Reference (pm_xxx)
+Commercial Commitment  → Payment Mandate + Subscription
+PCI Vault / Stripe     → CHD (downstream only, not canon)
+Evidence Source        → webhooks, mandate PDF, SCA audit
+```
+
+## Terminology Conflicts
+
+- **Payment method (Stripe)** vs. **Credential (canon)**: both grant "permission"
+  but different permission domains.
+- **Payment credential (informal)** vs. **Credential (glossary)**: avoid informal
+  phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
+- **Saved card** vs. **payment mandate**: saved token may exist before explicit
+  off-session mandate — lifecycle `proposed` until SetupIntent completes.
+- **customer_account (Stripe)** vs. **Account (login)**: reinforces commercial split.
+
+## Candidate Canonical Mappings
+
+| Source artifact | Canonical mapping |
+| --- | --- |
+| PAN / CVV | Out of canon (PCI downstream) |
+| PaymentMethod `pm_xxx` | Payment Instrument Reference |
+| SetupIntent succeeded | Payment Mandate Commercial Commitment + Evidence |
+| Subscription object | Commercial Commitment (subscription) |
+| Default payment method | Reference on Commercial Record |
+| Payment webhook | Evidence Source |
+| 3DS / SCA step-up | Evidence Source on mandate (not Credential) |
+| Passkey for login | Credential (unchanged) |
+
+## Open Questions
+
+- Network tokens (Visa VTS) — same Payment Instrument Reference pattern?
+- Shared payment methods across Stripe org customers — scope on reference.
+- Wallet balances (Stripe Customer balance) — Commercial Record attribute vs. commitment.
+
+## References
+
+- PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
+- Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
+- Stripe Customer object — https://docs.stripe.com/api/customers/object
+- Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
+- Internal: `../commercial-subscription/stripe-customer-billing.md`,
+  `reputation-assurance-gradient.md`, `commercial-identity-synthesis.md`