[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

SIPPING                                                      C. Jennings
Internet-Draft                                             Cisco Systems
Expires: January 17, 2006                                         G. Jun
                                                           Bitpass, Inc.
                                                               J. Fischl
                                                           SIP Edge, LLC
                                                           July 16, 2005

       Payment for Services in Session Initiation Protocol (SIP)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Communication systems require that a person receiving a call be able
   able to charge the caller when they are from different administrative
   domains.  This is necessary for making fair exchanges of service
   between two different communicating parties and is a major strategy
   for reducing the viability of SPAM.  This draft proposes an approach

Jennings, et al.        Expires January 17, 2006                [Page 1]

Internet-Draft                 SIP Payment                     July 2005

   for doing this in SIP.  The approach relies on a third party to act
   as a payment service provider and is optimized for very simple, low
   value transactions.  It does not provide the full range of services
   that are desirable in typical online trading systems.

   This draft is being discussed on the sipping@ietf.org mailing list.
   There is currently work to substantially change this draft to use

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3  Computing costs  . . . . . . . . . . . . . . . . . . . . .   7
     4.4  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . .   8
     4.5  Payment Service Provider Behavior  . . . . . . . . . . . .   8
     4.6  Customer and Merchant Enrollment and Transfer functions. .   8
     4.7  Account Names  . . . . . . . . . . . . . . . . . . . . . .   9
     4.8  Merchant Fetching Public Key . . . . . . . . . . . . . . .   9
   5.   SIP Extensions . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1  Update response code 402 . . . . . . . . . . . . . . . . .   9
   6.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1  Payment Offer  . . . . . . . . . . . . . . . . . . . . . .  10
     7.2  Request for Payment  . . . . . . . . . . . . . . . . . . .  13
     7.3  Receipt  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.4  Refunds  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.5  Computing Signatures . . . . . . . . . . . . . . . . . . .  16
     7.6  Verifying Signature  . . . . . . . . . . . . . . . . . . .  16
   8.   Replay Prevention  . . . . . . . . . . . . . . . . . . . . .  17
   9.   Usage Scenario . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1  SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.2  Micro Billing  . . . . . . . . . . . . . . . . . . . . . .  17
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  17
   11.  Security Consideration . . . . . . . . . . . . . . . . . . .  18
   12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
     12.1   Payment-Receipt Header . . . . . . . . . . . . . . . . .  18
     12.2   402 Response . . . . . . . . . . . . . . . . . . . . . .  18
     12.3   charge+xml . . . . . . . . . . . . . . . . . . . . . . .  18
   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  19
     13.1   Normative References . . . . . . . . . . . . . . . . . .  19
     13.2   Informational References . . . . . . . . . . . . . . . .  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  20
        Intellectual Property and Copyright Statements . . . . . . .  22

Jennings, et al.        Expires January 17, 2006                [Page 2]

Internet-Draft                 SIP Payment                     July 2005

1.  Introduction

   The scheme is simple and is optimized for low value transactions.  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 + Payment 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.  Additionally,
   M has the capability of providing a refund to C.

   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 time and opaque data it provided in the
   offer.  M can then check the signature is valid using P's public key.

Jennings, et al.        Expires January 17, 2006                [Page 3]

Internet-Draft                 SIP Payment                     July 2005

   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.  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.  While it is possible to develop schemes that deal with
   some of these problems, payment service providers deploying them have
   not been willing to provide services for transaction fees on the
   order of one US cent.  The authors believe that the simplified scheme
   presented here will make it easier to deploy systems that support
   these low value transactions.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [3].

   This work adopts the terminology from the framework in RFC 2801 [9].

   Customer: The entity that is paying for the call, typically the SIP

   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.  RFC 2801 refers to
   this as the Brand.

   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

   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 has occurred.

   Currency: Could be a classical currency such as the Euro or US Dollar
   or could be a pseudo currency such as airline mileage points.

Jennings, et al.        Expires January 17, 2006                [Page 4]

Internet-Draft                 SIP Payment                     July 2005

3.  Requirements

   Provide a system for callers to pay the person they are calling using
   a 3rd party clearing house.

   Support multiple currencies

   Support various billing models including: flat rate, per unit time,
   per unit data

   Cost effective for low cost transactions.

   Support anonymous customers

   Support simple refunds from merchants to customers

4.  Protocol

4.1  UAC Behavior

   The UAC SHOULD indicate that it can accept the application/charge
   MIME type in SIP requests it sends.

   In the case where the UAC receives a 402 response containing an
   application/charge 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 GET with the payment request encoded as parameters on the url.
   [Open Issue: Would a POST be better than a GET because this operation
   is not idempotent as it transfers currency from one account to
   another.]  The exact syntax of the HTTPS URL parameters is defined in
   section 7.  The UAC needs to look at the available Payment Service
   Providers, cost, and currency and select an appropriate one.  The UAC
   MUST copy the PaymentServiceProviderData fields from the offer into
   the Request for Payment parameters.  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 and currency parameters appropriately.
   Finally it needs to fill the CustomerData parameters.  It is critical
   that the UAC check the certificate of the HTTPS TLS connection as
   specified in RFC 2818 [5] and RFC 2246 [4].

   The response from the Payment Service Provider either will be an
   error or will contain a pay-receipt body.  The user needs to be
   informed if an error is received and the transaction SHOULD not be

Jennings, et al.        Expires January 17, 2006                [Page 5]

Internet-Draft                 SIP Payment                     July 2005

   retried unchanged.  When a valid response is received, the UAC SHOULD
   resubmit the SIP request that caused the 402 but this time include
   the pay-receipt in the Payment-Receipt header.

   The UAC needs to compute the amount of payment it wishes to make by
   looking at the costs provided.  This is described in section 4.3.
   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 new receipt with a SIP Re-
   INVITE or UPDATE transaction to the UAS.

4.2  UAS Behavior

   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/charge.  If it has, it MAY reject the request with a 402
   and attach an application/charge to the response.  Note that the
   application/charge document can be attached on any failure response.
   For example, this could allow a UAS to combine the offer with a
   request for authorization in a 401 response.  The syntax of the
   charge body is defined in section 7.  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
   list of currencies that are acceptable and what the cost in each one
   is.  The merchant may also specify a minimum cost and/or a maximum
   cost in the offer.  The costs are described in section 4.3.

   When the UAS receives a request that contains a pay-receipt in a
   Payment-Receipt header, it should check that this is valid, using
   these steps.  First, make sure the amount of the payment is
   appropriate and if it wishes, check that this is a receipt for an
   Offer it made.  Second, check that the signature of the Receipt is
   valid.  Computing and verifying the signatures is described in
   section 7.5.  Third, 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 RFC 1305 [7].
   Fourth, the UAS 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 UASs are using the same
   merchant-id at the Payment Service Provider, this replay detection
   needs to be done across all the UASs.  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

Jennings, et al.        Expires January 17, 2006                [Page 6]

Internet-Draft                 SIP Payment                     July 2005

   the call after the amount paid becomes inadequate to cover the
   session.  The UAS could use a mechanism like SIP session timer [12]
   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 certain cases where the Merchant may wish to offer a
   refund.  This could occur if the Customer has prepaid for a 10 minute
   session and the call terminates after 1 minute.  In this case, the
   Merchant may wish to provide a refund for the 9 minutes that were not
   used.  Alternatively, the Customer could provide a receipt to place a
   call but the destination is busy.  In this case, the Merchant would
   likely want to provide a full refund.

   The refund mechanism is simple and identical to the Payment Request
   procedure described in the section describing UAC Behavior.  In this
   case, the Merchant posts a Payment Request to the appropriate Payment
   Service Provider specified in the Payment Receipt.

   If the call ends early or can not be completed, it may still be
   possible that the Customer has provided a receipt of payment where no
   service has been delivered.  This may have occurred due to an
   upstream proxy error or a network connectivity issue between the UAC
   and the UAS.  Since the receipt of payment was never delivered to the
   UAS, there is no immediate mechanism of delivering a refund to the

4.3  Computing costs

   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 costs 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 and the currency divisor (power of
   10) was 1000 making the initial cost 300, the cost per unit time is
   40, 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.

   Note that the additional specification of a currency divisor allows

Jennings, et al.        Expires January 17, 2006                [Page 7]

Internet-Draft                 SIP Payment                     July 2005

   all currency amounts to be specified in fixed point.  In the above
   example, a currency divisor of 1000 means that all currency amounts
   are in tenths of a cent (USD).

4.4  Proxy Behavior

   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.

4.5  Payment Service Provider Behavior

   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 RFC 2818
   [5].  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:
   1.  Verify that the customer-id corresponds to a valid account and
       that the authorization credential is correct for that account.
       If this fails, the connection should be terminated.  An empty or
       error response MAY be sent.
   2.  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.
   3.  MUST form the Receipt by setting the PaymentServiceProviderData,
       currency information, amount, and merchant-id.
   4.  May set the PaymentData that the Payment Service Provider wishes
       to keep in the receipt.
   5.  MUST set the Date to the current time.
   6.  MUST compute and set the signature as described in section 7.5.
   7.  MUST transfer the money from the customer account to the merchant
   8.  MUST send the receipt as the HTTP response.

4.6  Customer and Merchant Enrollment and Transfer functions.

   The Payment Service Provider needs to provide a way for Customers and
   Merchants to enroll and transfer money in and out.  This is outside

Jennings, et al.        Expires January 17, 2006                [Page 8]

Internet-Draft                 SIP Payment                     July 2005

   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 mechanism for transfers to
   bank accounts.

4.7  Account Names

   Note: Need to define they syntax for valid account id.  Email style
   account names (where the host part is not the same as the PSP domain)
   need to be allowed.

4.8   Merchant Fetching Public Key

   The Merchant needs to be able to fetch the Payment Service Provider's
   public key.  This MAY be done by an HTTPS request to a URI provided
   by the Payment Service Provider.  The Merchant and Payment Service
   Provider should use some standard online certificate revocation
   mechanism to protect against the private key being compromised.  Note
   that the Payment Service Providers may wish to use signing
   certificates that are only valid for a short period of time.  The
   duration should be determined by the PSP based on the amount of money
   at risk.

5.   SIP Extensions

5.1  Update response code 402

   This document updates the 402 response code in RFC 3261 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 that more than one type of payment is required.  Both
   proxies and UASs can issue an 402.

6.  Example

   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 caller to help reduce SPAM.  The caller does not even bother to
   actually collect this 25 cents but donates it their favorite charity.

Jennings, et al.        Expires January 17, 2006                [Page 9]

Internet-Draft                 SIP Payment                     July 2005

      P                          C                         M
      |                          |  1) INVITE              |
      |                          |------------------------>|
      |                          |                         |
      |                          |  2) 402 + Payment Offer |
      |  3) Request for Payment  |<------------------------|
      |<-------------------------|                         |
      |                          |                         |
      |  4) Receipt              |                         |
      |------------------------->|  5) reINVITE + Receipt  |
      |                          |------------------------>|
      |                          |                         |
      |                          |  6) 200 OK              |
      |                          |<------------------------|
      |                          |                         |

   Still To Do - put in the rest of the messages for the example.  Worth
   noting that the INVITE will cary both SDP and the Payment Offer.
   These will be in two different bodies inside a multipart.

7.  Syntax

7.1  Payment Offer

   The Payment 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.  A Merchant can also specify a currency namespace with a
   particular cost.  This allows the Merchant to create non-standard
   currencies. e.g. airline mileage/points.  A cost can also specify an
   optional minimum and/or maximum cost.

   The currency is specified as 3 uppercase letters using the ISO
   currency code from ISO.4217.  All cost attributes (initialCost,
   costPerUnitTime, costPerUnitData, minCost, maxCost) are specified in
   currency units where the actual cost is to be divided by
   currencyDivisor.  All amounts are base 10 integers with no leading
   zeros and zero is not a valid entry.  The timeUnitSize is in
   milliseconds.  The dataUnitSize is in octets. merchantBits and
   pspBits are base 64 encoded data

   Each PaymentServiceProvider provided in a Payment Offer has a
   serviceUrl attribute which is where the PaymentRequest will be sent
   to.  There is also an optional url attribute which is a general HTTP
   URL that can provide information about the specific Payment Service

Jennings, et al.        Expires January 17, 2006               [Page 10]

Internet-Draft                 SIP Payment                     July 2005

   A simple example is provided with a single charge for a single
   Payment Service Provider where the initial cost is $0.25 and the
   charge is 0.06/minute charged in 6 second increments.

   <?xml version="1.0" encoding="UTF-8"?>
   <payOffer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     <offerData merchantBits="MDE1Mw=="
       <cost costPerUnitTime="6" initialCost="250" timeUnitSize="6000">
         <currency currency="USD" currencyDivisor="1000" />
           <currency currency="USD" currencyDivisor="1000"/>

   The body is defined with XML Schema.  The syntax is specified below.

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     <xs:element name="currency">
         <xs:attribute name="namespace" type="xs:string"
         <xs:attribute name="currency" type="xs:string"
         <xs:attribute name="currencyDivisor" type="xs:unsignedLong"
     <xs:element name="offerData">
         <xs:attribute name="expiry" type="xs:string"
         <xs:attribute name="merchantBits" type="xs:base64Binary"

Jennings, et al.        Expires January 17, 2006               [Page 11]

Internet-Draft                 SIP Payment                     July 2005

     <xs:element name="paymentServiceProvider">
           <xs:element name="currencies">
                 <xs:element ref="currency"/>
         <xs:attribute name="url" type="xs:anyURI"
         <xs:attribute name="serviceUrl" type="xs:anyURI"
         <xs:attribute name="merchantId" type="xs:unsignedLong"
         <xs:attribute name="pspBits" type="xs:base64Binary"
     <xs:element name="payOffer">
           <xs:element ref="offerData"/>
           <xs:element name="costs">
                 <xs:element name="cost">
                       <xs:element ref="currency"/>
                     <xs:attribute name="initialCost"
                                   use="optional" default="0"/>
                     <xs:attribute name="costPerUnitTime"
                                   use="optional" default="0"/>
                     <xs:attribute name="timeUnitSize"
                                   use="optional" default="0"/>
                     <xs:attribute name="costPerUnitData"
                                   use="optional" default="0"/>
                     <xs:attribute name="dataUnitSize"
                                   use="optional" default="0"/>

Jennings, et al.        Expires January 17, 2006               [Page 12]

Internet-Draft                 SIP Payment                     July 2005

                     <xs:attribute name="minCost"
                                   use="optional" default="0"/>
                     <xs:attribute name="maxCost"
                                   use="optional" default="0"/>
           <xs:element name="paymentServiceProviders">
                 <xs:element ref="paymentServiceProvider"/>

7.2  Request for Payment

   In order to make the generation of the Request for Payment as simple
   as possible for both the Customer and the Payment Service Provider,
   the RequestForPayment is constructed as an HTTP URL.  The Request for
   Payment consists of three main components.  The OfferData is copied
   from the Payment Offer from the Merchant.  The
   PaymentServiceProviderData is selected from the possible Payment
   Service Providers by the Customer.  The final component is the
   RequestData which includes the customer credentials with the chosen
   Payment Service Provider and the amount.  Note that it is up to the
   Customer to select a currency which is offered by the selected
   Payment Service Provider.

   The OfferData consists of the following fields from the Payment
   Request: offerExpiry and merchantBits.

   The PaymentServiceProviderData is copied from the chosen Payment
   Service Provider/Cost in the Payment Request consisting of the
   following fields: merchantId, serviceUrl, pspBits, currencyNamespace,
   currencyDivisor, and currency.

   The CustomerData is provided by the Customer and consists of the

Jennings, et al.        Expires January 17, 2006               [Page 13]

Internet-Draft                 SIP Payment                     July 2005

   following fields: customerId, customerAuth, customerBillingCode and
   an amount.  The customerBillingCode is optional and could be stored
   by the PaymentServiceProvider and included in the transaction history
   for the convenience of the Customer.  The amount divided by
   currencyDivisor indicates the amount of funds being requested to be
   transferred from the Customer to the Merchant in currency units.  The
   customerId is a token identifying the Customer's account with the
   Payment Service Provider and the customerAuth is the authentication

   The HTTP URL used for the Request for Payment takes on the form:

        paymentURL  =  "https://" hostport [ "/" hpath  ] "?" attributes
        hostport    = from section 5 of rfc1738
        hpath       = from section 5 of rfc1738
        attributes = offerExpiry "&" merchantBits "&" merchantId "&"
                     serviceUrl "&" pspBits "&"
                     [currencyNamespace "&"] currencyDivisor "&"
                     currency "&" customerId "&" customerAuth "&"
                     [customerBillingCode "&"] amount
        offerExpiry         = "offerExpiry=" date
        merchantBits        = "merchantBits=" token
        merchantId          = "merchantId=" token
        serviceUrl          = "serviceUrl=" token
        pspBits             = "pspBits=" token
        currencyNamespace   = "currencyNamespace=" token
        currencyDivisor     = "currencyDivisor=" token
        currency            = "currency=" ISO-currency-code
        customerId          = "customerId=" account
        customerAuth        = "customerAuth=" token
        customerBillingCode = "customerBillingCode=" token
        amount              = "amount=" token
        date                = from rfc3339
        qtext               = %d33 /      ; The rest of the US-ASCII
                              %d35-91 /   ; characters not including "\"
                              %d93-126    ; or the quote character
        account             = DQUOTE 1*qtext DQUOTE
        token               = quoted-string from rfc 2882
        ISO-currency-code   = DQUOTE 3*3(ALPHA) DQUOTE
        DQUOTE              = from rfc 2882
        ALPHA               = from rfc 2882

   Here is an example Payment Request based on the previous Offer
   example with a payment of $0.30.

Jennings, et al.        Expires January 17, 2006               [Page 14]

Internet-Draft                 SIP Payment                     July 2005


7.3  Receipt

   The Receipt is returned in the body of the response to the Request
   for Payment.  The body consists of a set of attributes formatted to
   be included as a SIP header in the reINVITE from the UAC.  The
   attributes placed in the Receipt by the Payment Service Provider are
   copied from the Request For Payment with the exception of the date
   and signature attributes.  The method of computing the signature is
   described in section 7.5.

   The following example receipt is returned from the HTTP POST to the
   Payment Service Provider and corresponds to a Receipt for a payment
   of $0.30.


   The following is the BNF for the Receipt:

Jennings, et al.        Expires January 17, 2006               [Page 15]

Internet-Draft                 SIP Payment                     July 2005

   receipt  =  attributes
   attributes = offerExpiry ";" merchantBits ";"
                merchantId ";" pspBits ";"
                receiptId ";" serviceUrl ";"
                [currencyNamespace ";"] currencyDivisor ";"
                currency ";" date ";" amount ";"
   offerExpiry         = "offerExpiry=" date
   merchantId          = "merchantId=" token
   merchantBits        = "merchantBits=" token
   receiptId           = "receiptId=" token
   serviceUrl          = "serviceUrl=" token
   currencyNamespace   = "currencyNamespace=" token
   currencyDivisor     = "currencyDivisor=" token
   currency            = "currency=" ISO-currency-code
   date                = from rfc3339
   amount              = "amount=" token
   pspBits             = "pspBits=" token
   signature           = "signature=" token
   token               = quoted-string
   ISO-currency-code   = from ISO.4217

7.4  Refunds

   Refunds share the same syntax as Request for Payment.  The Refund
   fields populated from the Receipt are: offerId, offerExpiry,
   merchantBits, merchantId, serviceUrl, pspBits, currencyNamespace,
   currencyDivisor, and currency.  The customerId and customerAuth refer
   to the Merchant's account information with the Payment Service
   Provider referenced by the serviceUrl.  The amount to refund is
   determined by the Merchant at the time of the refund.

7.5  Computing Signatures

   The signature in a receipt is computed across all the fields in the
   order specified in the BNF above (other than the signature field
   itself, of course).  The fields are defined so they have a clear and
   simple canonical form.  Only the contents of the attributes are used
   in the computation and this specifically does not include the name of
   the attribute or the double quotes.  RSA and SHA1 MUST be implemented
   for computing signatures.  The resulting signature is then base64
   encoded as specified in [6].

7.6  Verifying Signature

   Merchant needs to verify the signature in the Receipt to determine
   what to do.  A suggested verification involves

Jennings, et al.        Expires January 17, 2006               [Page 16]

Internet-Draft                 SIP Payment                     July 2005

   1.  Check ReceiptData.Date.  If too old, reject.
   2.  Check whether receipt-id has been accepted in a previous payment
       since the TTL used by the UAS.  If so, reject.  (See section 7.6
       on replay prevention)
   3.  Check whether Offer comes from this UAS.  If not, reject.
   4.  Perform RSA signature verification.  UAS chooses the public key
       based on PaymentServiceProvider-id

8.  Replay Prevention

   Replay detection.  If OfferData.offer-id contains device-id, the
   scope of replay detection can be limited to a single device.  TODO -
   add more here.

9.  Usage Scenario

9.1  SPAM

   Payment at risk has been suggested as part of a possible solution to
   SPAM in VoIP systems [10].  The idea is that A would call B. If A was
   not on B's white list, B could ask A to pay 5 cents for the privilege
   of ringing B's phone.  A could pay, and if B wished, B could refund
   the 5 cents by simply doing a second payment from B to A. The payment
   service provider would collect two transaction fees in this scenario.

   Another possible scenario is that B simply requests that A donate 5
   cents to one of B's favorite charities and show B the receipt for
   this transaction.

9.2  Micro Billing

   In this scenario, a merchant running a PSTN GW may charge a customer
   5 cents to connect and operate for the first 90 seconds and then may
   charge 5 more cents for each additional minute.  The customer would
   initially transfer 5 cents and then, before the 90 seconds ran out,
   would transfer another 5 cents and keep on doing this until the call

10.  Open Issues

   Would like to unify the body syntax so that it can also be used for
   Advice Of Charge information.

   Would like to change the term "offer" to "charge" to reduce confusion
   with SIP offer.

Jennings, et al.        Expires January 17, 2006               [Page 17]

Internet-Draft                 SIP Payment                     July 2005

11.  Security Consideration

   This system has many limitations and is appropriate only for low
   value transactions.  Much more is needed in this section, but some
   topics to cover include:
      Certificate loss and revocation.
      Credential loss.
      Recommendation on low value transactions only.
      Loss of receipt in TCP transfer.
      Payment handler can cheat Customer and Merchant.
      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.

12.  IANA Considerations

   This specification registers a new header and a new response code.
   IANA is requested to make the following updates in the registry at:
   http:///www.iana.org/assignments/sip-parameters.  It also defines a
   new mime type that IANA is requested to add to the registry at

12.1  Payment-Receipt Header

   Add the following entry to the header sub-registry.

     Header Name        compact    Reference
     -----------------  -------    ---------
     Payment-Receipt               [RFCXXXX]

12.2  402 Response

   Add the following entry to the response code sub-registry under the
   "Request Failure 4xx" heading.

       402  Payment Required                      [RFCXXXX]

12.3  charge+xml

Jennings, et al.        Expires January 17, 2006               [Page 18]

Internet-Draft                 SIP Payment                     July 2005

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/charge+xml

   MIME media type name: application

   MIME subtype name: charge+xml

   Required parameters: None

   Optional parameters: charset
   Same as charset parameter of application/xml [RFC3023]

   Encoding considerations:
   Same as for application/xml [RFC3023]

   Security considerations: TBD

   Interoperability considerations: TBD

   Published specification: None

   Applications which use this media type: Any MIME-compliant transport

   Additional information:
     Magic number(s): None
     File extension(s): None
     Macintosh File Type Code(s): None

   Person & email address to contact for further information:
     Cullen Jennings <fluffy@cisco.com>

   Intended usage: COMMON

   Author/Change controller:
     the IESG

13.  References

13.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  International Organization for Standardization, "Codes for the
        representation of currencies and funds", ISO Standard 4217,

Jennings, et al.        Expires January 17, 2006               [Page 19]

Internet-Draft                 SIP Payment                     July 2005

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [5]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
        RFC 3548, July 2003.

13.2  Informational References

   [7]   Mills, D., "Network Time Protocol (Version 3) Specification,
         Implementation", RFC 1305, March 1992.

   [8]   European Telecommunications Standards Institute,
         "Telecommunications and Internet Protocol Harmonization Over
         Networks (TIPHON); Open Settlement Protocol (OSP) for
         Interdomain pricing, authorization, and usage exchange",
         ETSI Technical  Specification 101 321.

   [9]   Burdett, D., "Internet Open Trading Protocol - IOTP Version
         1.0", RFC 2801, April 2000.

   [10]  Rosenberg, J. and C. Jennings, "The Session Initiation Protocol
         (SIP) and Spam", July 2004.

   [11]  Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

   [12]  Donovan, S. and J. Rosenberg, "Session Timers in the Session
         Initiation Protocol (SIP)", draft-ietf-sip-session-timer-15
         (work in progress), August 2004.

Authors' Addresses

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 902-3341
   Email: fluffy@cisco.com

Jennings, et al.        Expires January 17, 2006               [Page 20]

Internet-Draft                 SIP Payment                     July 2005

   Gyuchang Jun
   Bitpass, Inc.
   3300 Hillview Avenue, Suite 165
   Palo Alto, CA  94304

   Phone: 650 354-1882

   Jason Fischl
   SIP Edge, LLC
   PMB 267, 530 Divisadero Street
   San Francisco, CA  94117

   Phone: +1 415 554-0578
   Email: jason@sipedge.com

Jennings, et al.        Expires January 17, 2006               [Page 21]

Internet-Draft                 SIP Payment                     July 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Jennings, et al.        Expires January 17, 2006               [Page 22]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/