1.2.0-rc.1 / Payment profiles

Payment authentication

Authenticate an appointed verifier and bind its assertion to the accepted quote.

profiles/payment_adapter.py verifies a compact ES256 JWS with protected type odexa-payment-status+jws. Its only accepted protected members are alg, kid and typ; remote key references and algorithm substitution are rejected by the strict signature primitive. This role is explicitly enabled only by the payment adapter. It does not expand the draft-2 free service’s published key-use vocabulary.

The adapter first runs the delegated-authority resolver over exact current origin metadata and policy bytes. It requires verify_payments, the named service, exact endpoint, accepted-resource scope, per-check identity and digest, explicit delegation when external, and an active key authorized for the payment role. It obtains the public key from those digest-checked origin bytes. A provider cannot supply its own replacement trust key in the response.

After signature verification, commit_payment_response passes exact payload bytes and the resolved decision into the durable ledger. The payment state machine checks the retained quote, accepted offer/request, separate authenticated payer mandate, amount/currency, check identity, sequence, time and permitted transition. The ledger atomically retains the exact signed assertion with its authority context and resulting state. Invalid signature, removed delegation, revoked key, wrong scope, amount or check leaves financial state unchanged.

The observation of origin documents remains a trusted transport input. This module does not fetch them and a request body must never be accepted as proof of that observation. Nor does it authenticate a payer or create the accepted agreement: those must come from their separately authenticated workflows. Unit observations stand in for transport within this module; the separate network adapter now obtains them over verified HTTPS.

The provider signature establishes the provider’s assertion of an exact obligation’s status. It does not independently establish bank settlement, irrevocability or delivery of any asset. An active payment gate grants neither a policy permission nor a bearer token; the service and gateway must also satisfy their own checks. No method requests or repeats a debit.

Nine adapter tests exercise authenticated commit/retry, wrong signer/key/type, changed exact payload, signed wrong amount/check, removed or revoked authority, unavailable/unverified origin observations, isolation from the older free signature vocabulary, and actual write-lock waits across authority/key/access expiry. These are local cryptographic and persistence checks; the separate network adapter adds real provider HTTPS checks.

commit_payment_response uses a live callable/default clock and repeats full signature and authority evaluation after the ledger write lock is acquired. An optional trusted local-history guard rejects an observation already superseded locally. A scalar now remains available only for synthetic tests; a production caller must not freeze the pre-lock time. The original independently reproduced stale-time defect and its regression results are retained in the review record.

Odexa / Protocol explorer

This page. Your terms.

Inspect this website’s published policy and see how a proposed use is evaluated.

Current pagehttps://odexa.io/releases/1.2.0-rc.1/docs/payment-authentication/
Loading policy…

Published JSON
Open JSON

This is a local policy check, not a signed agreement or proof of agent compliance. Other published licences and applicable rights still apply. How policy evaluation works →

Odexa / Get in touch

Start a conversation.

Tell us what you have in mind. We’ll respond where we can.

We use these details to review and respond to your enquiry. Please leave out confidential information. Submitting does not subscribe you to marketing. Privacy policy.