Payment for SIP Services

Add HTTPS, TLS, and CMS references Payment handler can cheat customer and vendor Merchant can cheat customer. Things can simply get lost and cheat customer. Solutions like OSP are more complex but make these attacks less likely to be effective.

The scheme is very simple and is optimized for low value transactions and simplicity. It involves three parties: a consumer who is the caller, a merchant who is the person being called, and a common third party to broker the transaction, which is called the payment service provider.

P C M | | 1) Call | | |------------------------>| | | | | | 2) 402+Offer | | 3) Request for Payment |<------------------------| |<-------------------------| | | | | | 4) Receipt | | |------------------------->| 5) Call+Receipt | | |------------------------>| | | | | | 6) 200 OK | | |<------------------------| | | | In the figure above, the Customer or caller is labeled C, the Merchant or person being called is M, and the Payment Service Provider is P. Initially C makes a call to M. M determines that a payment is required and includes information about the payment in an Offer body of a 402 (Payment Required) response to C. C looks at this Offer and decides to make a payment. C instructs P to make a transfer from C's account to M's account and provides C with a Receipt for this transfer. C resubmits the call to M but this time provides the Receipt for the transaction. M determines whether it feels the Receipt is valid or not and allows the call. The Offer includes the third parties, P, that are acceptable to M, the amount of transaction, the account identifier for M at P, and specific transaction data determined by M to make it easier for M to avoid replay attacks. C includes this information when making the Request for Payment to P; adds its own account information and authorization password; and sends this to P, which produces a Receipt for the transaction if it is successful. This transfer from C to P is made across an encrypted, integrity protected channel. The Receipt includes a time when P made the transaction and a signature of the critical information in the Receipt made with P's public key. C resubmits the call to M with the Receipt from P. M can check for replay attacks using the date and opaque data it provided in the offer. M can then check the signature is valid using P's public key. HTTPS is used for the communications between P and C while SIP is used for the communications between C and M. This scheme does not provide for the tightest of security. There is no guarantee or recourse if M does not provide the service after C transfers money into M's account. No refunds are possible in the protocol. The system is designed for low value transactions in which, if M cheats, C can choose to never deal with M again but the value of the transaction is lost. This scheme is for online systems in which M, C and P can all communicate with real time messages. The system does not provide anonymous transactions.

MUST SHOULD This work adopts the terminology from the framework in 2801. Customer: The entity that is paying for the call, typically the SIP UAC. Merchant: The entity wishing to be paid for the call, typically the SIP UAS or a proxy in the same administrative domain as the UAS. Payment Service Provider (or PSP): The third party that handles the transfer of currency from Customer to Merchant. Offer: The information sent from the Merchant to the Customer describing what payment is needed. Request for Payment (or RFP): The information sent from the Customer to the Payment Service Provider describing the transfer of currency needed. Receipt: The information sent from the Payment Service Provider to the Customer and passed on to the Merchant. It provides confirmation that a particular transaction occurred. Brand: A Merchant may accept payments from several different Payment Service Providers. Each of these is referred to as a Brand. Each Brand may accept different type of currency. TODO - Note I would like a better term for this. Currency: Could be a classical currency such as the Euro or US Dollar or could be a pseudo currency such as airline mileage points.

Provide a system for callers to pay the person they are calling using a 3rd party clearing house. Work for very low value transactions. Support anonymous customers Not need to support refunds or guarantee that the 3rd party or prevent the Merchant from cheating.

The UAC SHOULD indicate that it can accept the application/pay-offer MIME type in SIP requests it sends. In the case where the UAC receives a 402 response containing an application/pay-offer body, it MUST check that this offer is acceptable to the user of the UAC. This could be done using a policy that was previously entered by the user. If the offer contains a Payment Service Provider with which the user has an account and the offer is acceptable, then the UAC sends a Request for Payment to the Payment Service Provider. This is done by setting up an HTTPS connection to the URL specified for the Payment Service Provider and performing an HTTP POST of the XML Payment document. The exact syntax of this document is defined in section XXX. The UAC MUST copy the LIST FIELDS HERE fields from the offer into the Request for Payment. The UAC needs to look at the available Brands, cost, and currency and select an appropriate one. The UAC must look at the cost elements in the offer to decide how large a payment the user wishes to make and set the amount field appropriately. Finally it needs to fill the LIST FIELDS. It is critical that the UAC check the certificate of the HTTPS TLS connection as specified in RFC XXXX. The response from the Payment Service Provider will either be an error or contain an application/pay-receipt body. The user needs to be informed if an error is received and the transaction SHOULD not be retried unchanged. When a valid response is received, the UAC SHOULD resubmit the SIP transaction that caused the 402 but this time attach the application/pay-receipt body to it. The UAC needs to compute the amount of payment it wishes to make by looking at the costs provided. This is described in section XXX. The UAC is also responsible for computing when the payments it has made will run out and refreshing the call with additional payments before this happens. For example, the UAC could initially decide to provide enough payment for 3 minutes. After 2.5 minutes it might decide to pay for an additional 3 minutes. It would do this by making a payment to the payment server for an additional 3 minutes' worth of resources and then sending the receipt with a SIP Re-INVITE or UPDATE transaction to the UAS.

When the UAS receives a request it wishes to charge for, it should check whether the UAC has set the Accept header to include application/pay-offer. If it has, it MAY reject the request with a 402 and attach an application/pay-offer to the response. The syntax of the pay-offer body is defined in section XXX. It needs to include lists of all the Payment Service Providers that are acceptable to the UAS and include the UAS's merchant-id at each one. It also needs to form a lists of currencies that are acceptable and what the cost in each one is. The costs are described in section XXX. When the UAS receives a request that contains an application/pay-receipt, it should check that this is valid with the following steps. Make sure the amount of the payment is appropriate and if it wishes, check that this is a receipt for an Offer it made. Check that the signature of the Receipt is valid. Computing and verifying the signatures is described in section XXX. Check that the time between the payment and now is acceptably low. This MUST be a configurable parameter and should default to 30 seconds. The UAS SHOULD support NTP (TODO REF). Next it MUST check that this receipt has not been previous used. The limited time window limits the amount of state the UAS must keep to make this check. If several UAS are using the same merchant-id at the Payment Service Provider, this replay detection needs to be done across all the UAS. The OfferData can be used with opaque encrypted data to help do this. If the payment is accepted, it is Merchant's responsibility to end the call after the amount paid becomes inadequate to cover the session. The UAS could use a mechanism like session timer (ADD REF) to perform this function. The UAC may send a Re-Invite or UPDATE with a new receipt for a payment to prolong the session. The UAS is provisioned with the URL and account numbers of Payment Service Providers that are acceptable, along with the certificate containing the public key for the Payment Service Provider. The expiry dates in this certificate MUST be checked and honored.

There are three types of costs: initial connection cost, cost per second, and cost per unit data. All three costs are added together to form the total cost and are assumed to be zero if not specified. The cost of the first time unit block size worth of time and the first data unit block size of data are considered to be included in the initial connection cost. If a call cost 30 cents to connect and then 12 cents per minute and is billed in 15 second increments (rounded down), the cost would be set so that the currency was USD, the initial costs was 0.3, the cost per unit time is 0.04, and the time unit size is 15000. If the time is to be rounded up, then some extra to cover the price of the first increment would be added to the connect cost.

In general a proxy does not do any special processing. A proxy in the same domain as the UAS MAY perform the UAS functions on behalf of the UAS. In this case the proxy performing this service would send the 402 to a request with no Receipt and would validate that the Receipt was acceptable before forwarding a request to the UAS.

The primary function of the Payment Service Provider is to receive Requests for Payments over HTTPS, transfer the currency from one account to another, and return a Receipt over HTTPS. A Payment Service Provider MUST support HTTPS. When it receives a new connection it MUST present a valid TLS certificate that corresponds to its domain in the normal ways specified in TODO REF. The cipher suite negotiated must be encrypted and integrity protected because sensitive information is going to be transferred over this connection. When a Payment Service Provider receives a Request for Payment, it performs the following steps: Verify that the customer-id corresponds to a valid account and that the authorization credential is correct for that account. (TODO - consider using HTTP Digest here instead ). If this fails, the connection should be terminated. An empty or error response MAY be sent. MUST validate that the currency is acceptable by the Merchant, that the Customer has appropriate funds, and that the merchant-id corresponds to a valid account. MUST form the Receipt by setting the PaymentServiceProviderData, currency information, amount, and merchant-id. May set the PaymentData that the Payment Service Provider wishes to keep in the receipt. MUST set the Date to the current time. MUST compute and set the signature as described in section XXX. MUST transfer the money from the customer account to the vendor account. MUST send the receipt as the HTTP response.

The Payment Service Provider needs to provide a way for Customers and Merchants to enroll and transfer money in and out. This is outside the scope of this document but could be done using web forms to enroll, get an account number, and provide the typical credit card mechanism to transfer money into the account. Transfers out of the account could be done with the typical transfer to bank accounts mechanism.

TODO - define syntax for valid account id. Allow email style account name (where the host part is not the same as the PSP domain).

The Merchant needs to be able to fetch the Payment Service Provider's public key. This is done by an HTTPS request to a URI provided by the Payment Service Provider. REF DOC on how to do. It is suggested that Payment Service Providers use signing certificates that are only valid for a short period of time - in the order of 1 to 7 days.

This document updates 402 to mean that "A Payment is Required". Other mechanisms are used to indicate what type of payment is required. In the case of this draft, a particular MIME body type indicates the type of payment required. A single 402 may indicate more than one type of payment is required.

The following example shows a simple call where the caller is not recognized by the callee and the callee wants to charge 25 cents to the callee to help reduce SPAM. The caller does not even bother to actually collect this 25 cents but donates it their favorite charity.

The Offer contains a lists of costs and a list of Payment Service Providers. The Customer can choose to pay any one of the provided costs and can choose any one of the Payment Service Providers to use, as long as the PSP supports the currency for the chosen cost. Notes on types: The types are all constructed so that they have a clear canonical form for computing the signatures and so that "|" can be used a separator between them. Currency: if ISO, then 3 upper case letters. Amount: decimal number. If greater than or equal to 1, no leading zeros; otherwise must start with 0. No trailing 0. Must not have more than 8 digits to the left of the decimal point and not more than 6 digits to the right of the decimal point. Vendor ID: base 10 integer, 64 bits, no leading zeros, 0 not valid. Customer ID: base 10 integer, 64 bits, no leading zeros, 0 not valid. CustomerData: base64 encoded data. MerchantData: base 64 encoded data. PaymentData: base64 encoded data.

Offer * Cost List * Cost - currency name space - currency: 3 uppercase letters, ISO currency code - initial cost - cost per unit time - time unit size in milliseconds - cost per unit data - data unit size in octets * Brand List * Brand * PaymentServiceProviderData - id: domain name as a unique identifier for PSP - URL: general http URL to learn about the PSP - URL for RCP: URL to send the payment request - supported currencies: list of currencies supported by this brand of PSP TODO TBD if this is needed - merchant-id: merchant's account # at this PSP - Accepted currencies: list of currencies accepted through this brand of PSP - PSP Bits: some data provided by PSP * OfferData - offer-id: - offerExpirey date: ISO format UTC - MerchantBits: some bits provided by vendor

Request for Payment * Brand; copied from Offer - ... - ... * CustomerData - customer-id: customer's account # at this PSP - customer authorization: authorization credential * RequestData - currency - amount * OfferData; copied from Offer - ... - ... Note: Request for Payment will be an HTTP message, which has fewer size restrictions. Therefore Customer does not need to try to reduce the size of the request. Generating the Request for Payment is mostly copying chunks from Offer

Receipt - receipt-id: - 64bit integer - PaymentServiceProvider-id * OfferData; copied from RFP - ... - ... * ReceiptData - Date: ISO format UTC time - currency namespace - currency - amount - digest - hash * PaymentData (optional) - bits provided by PSP - SignatureData

The signature in a receipt is computed across all the fields (other than the signature field itself, of course). The fields are defined so they have a clear and simple canonical form. A "|" separator is used between the fields. RSA and SHA1 MUST be implemented for computing signatures.

Merchant needs to verify the signature in the Receipt to determine what to do. A suggested verification involves Check ReceiptData.Date. If too old, reject. Check whether receipt-id has been accepted in a previous payment since the TTL used by the UAS. If so, reject. (See section XXX (REPLAY)) Check whether Offer comes from this UAS. If not, reject. Perform RSA signature verification. UAS chooses the public key based on PaymentServiceProvider-id

Replay detection. If OfferData.offer-id contains device-id, the scope of replay detection can be limited to a single device. If the device has a policy of generating up to two offers per second and specifying the offer-id as "<device-id>.<0|1>.(some random string)", then verifying OfferData.hash is sufficient to ensure the uniqueness of the offer.

TODO - decide if this is useful or not. Verification procedure MAY differ from what suggested here, depending on the Merchant's policy. This suggested example enables the Merchant to verify the signature more efficiently. Verifying the hash before doing RSA signature verification will help the Merchant spot the forgery without wasting its CPU time on computationally intensive RSA verification. Verify ReceiptData.hash. If fails, reject. (recompute hash and compare with given hash) Verify Offer.hash Compute a digest of Brand.hash + Offer.hash + ReceiptData.hash (+: string concat.) - Merchant chooses right Brand.hash based on PaymentServiceProvider-id

Header or body?

Certificate loss and revocation. Credential loss. Recommendation on low value transactions only. Merchant IDs cannot be used a customer IDs. Helps keep money in a customer account low. Loss of receipt in TCP transfer.

Need MIME types for Offer, Payment, and Receipt.