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)
draft-jennings-sipping-pay-02
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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
SAML.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
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. 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
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 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
Customer.
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
account.
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
Provider.
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.
The body is defined with XML Schema. The syntax is specified below.
Jennings, et al. Expires January 17, 2006 [Page 11]
Internet-Draft SIP Payment July 2005
Jennings, et al. Expires January 17, 2006 [Page 12]
Internet-Draft SIP Payment July 2005
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
credentials.
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
https://psp.example.com/paymentService?
offerExpiry="2005-02-01T13:40:26.52Z"&
merchantBits="MDE1Mw=="&merchantId="15"&
serviceUrl="https://psp.example.com/paymentService"&
pspBits=""&
currencyDivisor="1000"¤cy="USD"&
customerId="joe"&customerAuth="xxxx"&
amount="300"
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.
offerExpiry="2005-02-28T23:20:50.52Z";
merchantBits="MDE1Mw==";
merchantId="15";
pspBits="";
serviceUrl="https://psp.example.com/paymentService";
currencyDivisor="1000";
currency="USD";
date="2005-02-28T22:20:51.52Z";
amount="300";
signature="XXXXXXX"
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 ";"
signature
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
ended.
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
http://www.iana.org/assignments/media-types/application.
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
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,
2001.
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
USA
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
USA
Phone: 650 354-1882
Jason Fischl
SIP Edge, LLC
PMB 267, 530 Divisadero Street
San Francisco, CA 94117
USA
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings, et al. Expires January 17, 2006 [Page 22]