Generic SPT Spec

[armsteadj1]

Summary

Adds a processor-neutral Shared Payment Token (spt) charge method profile for HTTP Payment Authentication, plus a concrete Stripe bridge example.

The goal is to let servers advertise one generic SPT payment method while allowing client/server enablers to fulfill and redeem the payment through Stripe or another SPT-capable processor without leaking processor-specific object models into the HTTP challenge.

What changed

• Adds specs/methods/spt/draft-spt-charge-00.md.
  • Defines the generic spt method identifier for one-time charge payments.
  • Specifies challenge request fields, credential payload shape, token issuance requirements, verification, replay protection, settlement, receipts, error handling, discovery, marketplace settlement boundaries, security/privacy considerations, and conformance requirements.
  • Keeps settlement policy server-side so clients cannot control fees, account routing, destination accounts, or platform settlement behavior.
• Adds examples/spt-stripe-bridge.md.
  • Shows how a generic method="spt" challenge can be fulfilled with a Stripe Shared Payment Token through Stripe-specific adapters.
  • Maps generic recipient/allowance fields to current Stripe SPT concepts such as seller_details.network_business_profile, usage_limits, and payment_method_data.shared_payment_granted_token.
• Updates examples/README.md to link the Stripe bridge example.

Design notes

• The generic HTTP credential carries an opaque sharedPaymentToken plus a selected processor identifier; processor-specific details stay behind client/server enabler adapters.
• Processor selection is modeled with methodDetails.processors[], so a server can offer multiple SPT-capable processors without creating one HTTP payment method per processor.
• Recipient and marketplace settlement details are deliberately split:
  • payer-visible recipient context can be included and challenge-bound;
  • account routing, platform fees, transfer destinations, and reconciliation policy remain trusted server-side settlement policy.
• The profile treats SPTs as bearer credentials, requires single-use processor redemption, and recommends server-side replay/idempotency protection keyed by challenge, processor, and token hash.
• Ambiguous processor outcomes are handled explicitly so retries do not create duplicate payable transactions.

Validation

Passed locally:

• git diff --check
• python scripts/lint_frontmatter.py
• python scripts/lint_external_section_refs.py
• SPT draft render/validation:
  • kramdown-rfc specs/methods/spt/draft-spt-charge-00.md
  • xml2rfc --text --no-pagination artifacts/draft-spt-charge-00.xml
  • xml2rfc --html --no-pagination artifacts/draft-spt-charge-00.xml
  • rfclint --no-rng --no-spell artifacts/draft-spt-charge-00.xml

Not run locally:

• Full Docker-backed repo render/check. Local Docker is unavailable on my machine; the SPT draft itself renders and validates with the local kramdown-rfc/xml2rfc path above.