One document matched: draft-jennings-sipping-pay-06.txt
Differences from draft-jennings-sipping-pay-05.txt
SIPPING C. Jennings
Internet-Draft Cisco Systems
Intended status: Standards Track J. Fischl
Expires: January 9, 2008 CounterPath Solutions, Inc.
H. Tschofenig
Siemens Networks GmbH & Co KG
G. Jun
Bitpass, Inc.
July 8, 2007
Payment for Services in Session Initiation Protocol (SIP)
draft-jennings-sipping-pay-06.txt
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 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Service usage might require some form of compensation and this is
also true for many communication systems where an entity receiving a
call should be able to charge the caller. This is necessary for
Jennings, et al. Expires January 9, 2008 [Page 1]
Internet-Draft SIP Payment July 2007
allowing fair communication between two communicating parties and is
a major strategy for reducing the viability of SPAM. This draft
proposes an approach for doing this in SIP using the Security
Assertion Markup Language (SAML). It relies on a third party to act
as a payment provider and is designed for low value transactions. It
does not aim to provide the same capability as other authentication,
authorization and accounting backend infrastructures.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. SAML Payment Scenario using Assertions . . . . . . . . . . 4
1.2. SAML Payment Scenario using URI References . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Requirements, Assumptions and Goals . . . . . . . . . . . . . 9
4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Extended SIP SAML Profile . . . . . . . . . . . . . . . . . . 10
5.1. New Option Tags and a SAML Header Created . . . . . . . . 10
5.2. 424 (Bad SAML Information) Response Code . . . . . . . . . 13
6. SIP Payment Protocol . . . . . . . . . . . . . . . . . . . . . 13
6.1. UAC Behavior (Customer) . . . . . . . . . . . . . . . . . 13
6.2. UAS Behavior (Merchant) . . . . . . . . . . . . . . . . . 14
6.3. Computing costs . . . . . . . . . . . . . . . . . . . . . 16
6.4. Transition Scenarios . . . . . . . . . . . . . . . . . . . 16
6.4.1. Merchant Proxy . . . . . . . . . . . . . . . . . . . . 16
6.4.2. Customer Proxy . . . . . . . . . . . . . . . . . . . . 18
6.5. Payment Provider Behavior . . . . . . . . . . . . . . . . 20
6.6. Merchant Fetching Public Key . . . . . . . . . . . . . . . 21
7. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Update response code 402 . . . . . . . . . . . . . . . . . 21
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Payment Offer . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Request for Payment . . . . . . . . . . . . . . . . . . . 23
8.3. Payment Receipt . . . . . . . . . . . . . . . . . . . . . 25
8.4. Refunds . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.5. Verifying the Receipt . . . . . . . . . . . . . . . . . . 27
9. Usage Scenarios for SIP Payment . . . . . . . . . . . . . . . 28
9.1. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Micro Billing . . . . . . . . . . . . . . . . . . . . . . 28
10. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. PaymentOffer XML Schema . . . . . . . . . . . . . . . . . 28
10.2. Payment Request . . . . . . . . . . . . . . . . . . . . . 31
10.3. Payment Receipt . . . . . . . . . . . . . . . . . . . . . 33
11. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12.1. Stolen Assertion . . . . . . . . . . . . . . . . . . . . . 35
12.2. MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 35
Jennings, et al. Expires January 9, 2008 [Page 2]
Internet-Draft SIP Payment July 2007
12.3. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 36
12.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 36
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
13.1. Payment-Receipt Header . . . . . . . . . . . . . . . . . . 36
13.2. 402 Response . . . . . . . . . . . . . . . . . . . . . . . 37
13.3. charge+xml . . . . . . . . . . . . . . . . . . . . . . . . 37
13.4. IANA Registration for the SIP SAML Header . . . . . . . . 38
13.5. IANA Registration for Two New SIP Option Tags . . . . . . 38
13.6. IANA Registration for Response Code 4XX . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . . 38
15.2. Informational References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41
Jennings, et al. Expires January 9, 2008 [Page 3]
Internet-Draft SIP Payment July 2007
1. Introduction
Service usage might require some form of compensation and this is
also true for many communication systems where an entity receiving a
call should be able to charge the caller. This is necessary for
allowing fair communication between two communicating parties and is
a major strategy for reducing the viability of SPAM. This draft
proposes an approach for doing this in SIP using the Security
Assertion Markup Language (SAML). It relies on a third party to act
as a payment provider and is designed for low value transactions. It
does not aim to provide the same capability as other authentication,
authorization and accounting backend infrastructures.
This document creates SAML profiles and bindings in addition to those
specified in [1]. Although this document provides a very specific
usage scenario for SAML usage within SIP it is written in a generic
way to support other usage scenarios following the same communication
pattern. This approach is inline with the idea of SAML. The
abstract model allows a SAML assertion or an URI reference to a SAML
assertion to be requested from a trusted third party via HTTP. The
SAML assertion or URI reference is returned to the requesting party.
Then, it is conveyed in SIP to another party that is performing an
authorization decision based on the received information. To resolve
a URI reference into a SAML assertion it is additionally necessary to
contact the trusted third party using HTTP (see [1]).
Section 1.1 shows the basic message exchange using SAML assertions
and Section 1.2 shows a variation with URI references to SAML
assertions. Both message exchanges show the high-level SIP payment
interaction where three parties are involved:
o a consumer who is the caller (or SAML requester),
o a merchant who is the person being called (or SAML responder),
o and the Payment Provider (or SAML Authority).
1.1. SAML Payment Scenario using Assertions
Jennings, et al. Expires January 9, 2008 [Page 4]
Internet-Draft SIP Payment July 2007
P C M
| | 1) Call |
| |------------------------>|
| | |
| | 2) 402 + Payment Offer |
| 3) Request for |<------------------------|
| a Payment | |
|<-------------------------| |
| | |
| 4) SAML Assertion | |
| (=Receipt) | |
|------------------------->| |
| | 5) Call + Receipt |
| |------------------------>|
| | |
| | 6) 200 OK |
| |<------------------------|
| | |
Figure 1: Overview for SAML Assertion Handling
The Customer (C) and the Merchant (M) interact with each other using
SIP and the Customer uses HTTP to exchange messages with the Payment
Provider (P). Initially, C makes a call to M (1). 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 (2). C looks
at this Offer and decides to make a payment. The Customer instructs
its Payment Provider to make a transfer from the Customer's account
to the Merchants's account (3) using a request for a SAML assertion
with the extensions defined in this document. The Payment Provider
returns a receipt for this transfer (4). This receipt is a SAML
assertion. C resubmits the call to M but this time provides the
Receipt for the transaction (5). If the authorization was
successful, M determines whether the Receipt is valid (by checking
the digital signature and the content of the assertion) and continues
with the call processing.
The Offer contains information about the parties P, that are
acceptable to M, the amount of the transaction, the account
identifier for M at P, and random data (carried in the merchantBits
field) 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 timestamp when P made the
transaction and protects the Receipt with a digital signature. C
resubmits the call to M with the Receipt from P. M can check for
Jennings, et al. Expires January 9, 2008 [Page 5]
Internet-Draft SIP Payment July 2007
replay attacks using the timestamp and the merchantBits initially
provided with the Offer. M can then check the signature is valid
using P's public key.
1.2. SAML Payment Scenario using URI References
This section shows a variation of the message exchange presented in
Section 1.1 with the difference that C requests a URI reference
rather than an assertion (see message 3). The Payment Provider
creates a SAML assertion after authentication and authorization and
crafts a URI reference that points to it, which is then returned to C
as part of a successful response message (see message 4). This URI
reference is then forwarded to M in message 5. When M wants to
resolve the URI reference to an assertion it uses the 'SIP SAML URI-
based Assertion Fetch Profile' described in Section 6.1 of [1]. This
exchange is shown in message 6 and 7. The receipt is carried in a
SIP header.
P C M
| | 1) Call |
| |------------------------>|
| | |
| | 2) 402 + Payment Offer |
| 3) Request for |<------------------------|
| a Payment | |
|<-------------------------| |
| | |
| 4) SAML URI Reference | |
| (=Receipt) | |
|------------------------->| |
| | 5) Call + Receipt |
| |------------------------>|
| | |
| 6) HTTP URI Resolution |
|<---------------------------------------------------|
| | |
| 7) HTTP/1.1 200 OK & Assertion |
|----------------------------------------------------|
| | |
| | 8) 200 OK |
| |<------------------------|
| | |
Figure 2: Overview for SAML URI Reference Handling
Figure 1 and Figure 2 do not show the interaction between the
Merchant and the Customer if refunding is necessary. Additionally,
Jennings, et al. Expires January 9, 2008 [Page 6]
Internet-Draft SIP Payment July 2007
the interaction between the Merchant and the Payment Provider to
reconcile is not shown in these two figures. Further message
exchanges that are shown as transition scenarios (see Section 6.4)
finish the message exchange.
The proposal described in this document does not aim to provide
functionality equivalent to AAA protocols. For example, 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 designed for systems whereby the communication between M and C and
the communication between C and P can be executed in real time.
While it is possible to develop schemes that deal with some of these
problems, Payment 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 reach 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 [2].
This work adopts the terminology from the framework in RFC 2801 [13].
Additionally, the following terms are used:
Customer:
The entity that is paying for the call, typically the SIP User
Agent Client (UAC) or a proxy in the same administrative domain as
the UAC.
Merchant:
The entity wishing to be paid for the call, typically the SIP User
Agent Server (UAS) or a proxy in the same administrative domain as
the UAS.
Payment Provider:
The third party that handles the transfer of funds from Customer
to Merchant. The Internet Open Trading Protocol (IOTP) [13]
refers to this as the Brand.
Jennings, et al. Expires January 9, 2008 [Page 7]
Internet-Draft SIP Payment July 2007
Offer:
The information sent from the Merchant to the Customer describing
what payment is needed.
Request for Payment:
The information sent from the Customer to the Payment Provider
describing the transfer of currency needed. This request is
implemented as a request for a SAML assertion.
Receipt:
The information sent from the Payment Service Provider to the
Customer and passed on to the Merchant. The Receipt is either a
SAML assertion or a URI reference to a SAML assertion. The
Receipt tells the Customer that the payment transaction was
successfully completed (if either a SAML assertion or a SAML URI
reference is returned). The Merchant receives an assurance that
the transaction was successful after receiving the Receipt and
verifying it succesfully.
Currency:
Could be a classical currency such as the Euro or US Dollar or
could be a pseudo currency such as airline mileage points.
Assertion:
An assertion is an XML document that contains authentication
statements, attribute statements and authorization decision
statements. In an authentication statement, an issuing authority
asserts that a certain subject was authenticated by certain means
at a certain time. In an attribute statement, an issuing
authority asserts that a certain subject is associated with
certain attributes which has certain values. In an authorization
decision statement, a certain subject with a certain access type
to a certain resource has given certain evidence that the identity
is correct. The assertion is digitally signed to protect it
against unwanted modifications by third parties.
HTTP-based SAML URI Reference:
The SAML URI Binding specifies a means by which SAML assertions
can be referenced by URIs and thus be obtained through resolution
of such URIs. These references point to a server that temporarily
stores an assertion. An advantage of SAML URI Bindings is that
Jennings, et al. Expires January 9, 2008 [Page 8]
Internet-Draft SIP Payment July 2007
they may be placed into a SIP header by intermediate SIP proxy
elements.
For further terminology related to SAML the reader is referred to
[3].
3. Requirements, Assumptions and Goals
This section lists some basic requirements and goals for the protocol
presented in this document. This document extends the SIP SAML
profile and binding described in [1] and describes a usage scenario
utilizing these extensions, namely SIP payment. The goals and
assumptions below refer to the application of SAML usage for SIP
payment.
o Provide a system for callers to pay the person they are calling
using a 3rd party clearing house. A trust relationship between
the Merchant and the Payment Provider and between the Customer and
the Payment Provider must exist. The Customer must be able to
authenticate itself to the Payment Provider and to instruct the
Payment Provider to transfer money from its account to another
account (i.e., the account of the Merchant). It is not necessary
for the Customer and Merchant to have a direct relationship with
each other. The Payment Provider acts as a clearinghouse.
o The protocol must support multiple currencies and must offer the
ability for the Customer to learn the price before initiating a
transaction.
o Support various billing models including: flat rate, per unit
time, per unit data
o The solution must be cost effective for low cost transactions.
o The solution must allow Customers to remain anonymous towards the
Merchants.
o Support for a simple refund mechanism must be provided.
4. Non-Goals
There needs to be a mechanism for Customers and Merchants to enroll
and transfer money in and out of their accounts. The mechanisms to
accomplish this functionality are outside the scope of this document.
They can be provided by using web forms to enroll, obtain 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 wire transfer mechanism to bank accounts.
Jennings, et al. Expires January 9, 2008 [Page 9]
Internet-Draft SIP Payment July 2007
5. Extended SIP SAML Profile
Several push-based SIP Request Methods are capable (and applicable)
of carrying a SAML assertion or URI reference, including:
o INVITE,
o REGISTER,
o UPDATE, and
o MESSAGE,
More than one SAML assertion or URI reference to a SAML assertion MAY
be included in the same message body part.
While the authors do not yet see a reason to have payment receipts
carried in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not
see a reason to prevent carrying a SAML assertion or a URI reference
within these Method Requests as long as the SIP message meets the
requirements stated within this document.
SIP end points SHOULD use SIP Identity [4] to tie the SAML assertion
to the SIP message end-to-end. Furthermore, in addition to the
protection provided by SIP Identity, the security protection
equivalent to SIPS SHOULD be used (i.e., channel security hop-by-hop
between the involved signaling entities). This ensures that
eavesdroppers located along the signaling path are unable to
eavesdrop an assertion in transit. This is mainly a mechanism to
ensure privacy of the transmitted information. Since SIP proxies are
therefore still able to see the assertion in clear it is necessary to
include enough information in the SAML assertion in order to prevent
replay attacks. For more information about replay attacks regarding
SAML and SIP the reader is referred to Section 9 of [1].
Self-signed certificates should only be used in combination with [5]
for protecting a SAML assertion (or a URI reference).
SIP Methods such as SUBSCRIBE and NOTIFY (in combination with
PUBLISH) are considered a pull-based mechanism, and will be discribed
in a future version of this document.
5.1. New Option Tags and a SAML Header Created
This document creates and IANA registers two new option tags, "SAML"
or "unable-SAML". User agent clients who support this specification
will indicate that support by including either of these option-tags
in a Supported header.
This document also creates and IANA registers a new SAML header. The
SAML header, if present, will have one of three header values defined
by this document:
Jennings, et al. Expires January 9, 2008 [Page 10]
Internet-Draft SIP Payment July 2007
o a HTTP URI Reference to a SAML assertion
o a Content ID indicating where the SAML assertion or URI reference
to a SAML assertion is within the message body
o a SAML based option tag
A URI reference to a SAML assertion is a pointer to a record on a
remote node containing the SAML assertion.
If the SAML assertion is contained in a SIP message, a SAML header
will be present in the message with a content-ID (cid-url) [6]
indicating where in the message body a SAML assertion or a URI
reference is for this UA. This is to aid a node in not having to
parse the whole message body or body parts looking for this body
type.
The Unknown-SAML option tag in a SAML header indicates a UA
understands the concept of SAML conveyance, but does not have the
desired SAML assertion to provide. This can save error messages from
being generated looking for an answer the UA does not have to give.
It can also allow a processing entity the immediate knowledge it
needs to act as if the UA will not learn SAML on its own, and perhaps
call on another process to address the needs for that message.
The new "SAML" header has the following BNF syntax:
SAML = "SAML" HCOLON SAML-value *(COMMA
SAML-value)
SAML-value = (addr-spec / option-tag / token)
addr-spec = cid-url / absoluteURI
option-tag = string
token = token / quoted-string
cid-url = "cid" ":" content-id /
absoluteURI = SIP or SIPS-URI
content-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
The Content-ID (cid) is defined in [6] to locate message body parts.
The absoluteURI is the SIP or SIPS URI of the reference, which points
at a SAML of a UA in a record on a remote node.
The following table extends the values in Table 2/3 of RFC 3261 [7].
Jennings, et al. Expires January 9, 2008 [Page 11]
Internet-Draft SIP Payment July 2007
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
SAML Rr ar o - - o o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
SAML Rr ar - - o o o o -
The SAML header MAY be added, or read if present in a Request message
listed above. A proxy MAY add the SAML header in transit if one is
not present. [7] states message bodies cannot be added by proxies. A
proxy MAY read the SAML header in transit if present.
It is RECOMMENDED that only one SAML header be in the same message,
but this is not mandatory.
Here is an example INVITE that includes the proper SAML and Supported
headers (without the SAML message body part):
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
SAML: cid:alice123@atlanta.example.com
Supported: SAML
Accept: application/sdp, application/samlassertion+xml
CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP here
--boundary1
Content-Type: application/samlassertion+xml
Content-ID: alice123@atlanta.example.com
...SAML assertion in here
Jennings, et al. Expires January 9, 2008 [Page 12]
Internet-Draft SIP Payment July 2007
--boundary1--
The SAML header from the above INVITE:
SAML: cid:alice123@atlanta.example.com
indicates the Content-ID SAML [6] within the multipart message body
of were the SAML assertion is.
If the SAML header were this instead:
SAML: https://example.com/assns/?ID=abcde
this would indicate that a URI reference to a SAML assertion was
included in this message and no SAML body would be required.
5.2. 424 (Bad SAML Information) Response Code
In the case that a UAS or SIP intermediary detects an error in a
Request message specific to the SAML assertion supplied by-value or
by-reference, a new 4XX level error is created here to indicate this
is the problem with the request message. This document creates the
new error code:
424 (Bad SAML Information)
The 424 (Bad SAML Information) Response code is a rejection of the
SAML contents, whether by-value or by-reference of the original SIP
Request. The server function of the recipient (UAS or intermediary)
has deemed this URI reference to a SAML assertion or the SAML
assertion to be bad. No further action by the UAC is required. The
UAC can use whatever means it knows to verify/refresh its SAML
information before attempting a new request. There is no cross-
transaction awareness expected by either the UAS or SIP intermediary
as a result of this error message.
This new error code will be IANA registered in Section 13.
6. SIP Payment Protocol
6.1. UAC Behavior (Customer)
The UAC SHOULD indicate that it can accept the application/charge
MIME type in SIP requests it sends.
Jennings, et al. Expires January 9, 2008 [Page 13]
Internet-Draft SIP Payment July 2007
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
Provider with which the user has an account and the offer is
acceptable, then the UAC sends a Request for Payment to the Payment
Provider.
The UAC needs to look at the available Payment 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 [8] and RFC 2246 [9].
After selecting and constructing the SAML request message it is sent
over the HTTPS secured connection. The detailed format of the
request is shown in Section 10.
The response will be either an error, a SAML assertion or a URI
reference. 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 request that
caused the 402 but this time by including the Receipt (i.e., the URI
reference or the SAML assertion).
The UAC needs to compute the amount of payment it wishes to make by
looking at the cost information provided as part of the Offer. The
UAC is also responsible for determining when a new payment has to be
made and refreshing the call with additional payments before this
happens. For example, the UAC could initially decide to provide
enough payment for a 3 minute call. After 2.5 minutes the UAC might
decide to pay for an additional 3 minutes. It would do this by
issuing a new Payment Request to the Payment Provider 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.
6.2. UAS Behavior (Merchant)
When the UAS receives a request it wishes to charge for, the UAS
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
Jennings, et al. Expires January 9, 2008 [Page 14]
Internet-Draft SIP Payment July 2007
request for authorization in a 401 response. It needs to include
lists of all the Payment Providers that are acceptable to the UAS and
include the identity of the Merchant. 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 6.3.
When the UAS receives a request that contains a Receipt (as a SAML
assertion) as defined in [1], the UAS MUST verify that the assertion/
artifact is valid using the following steps.
1. Ensure that the amount of the payment is appropriate and if this
receipt matches to a previous Offer to prevent replay attacks.
2. Check that the digital signature of the Receipt is valid. This
includes path validation and to check that the certificate of
Payment Provider is still valid.
3. 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 [14]. [Editor's
Note: Is this mechanism really needed?]
4. 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, 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 the Merchant's responsibility to end
the call after the amount paid becomes inadequate to cover the
session. The UAS SHOULD use a mechanism like that specified in SIP
session timer [15]. The UAC MAY send a re-INVITE or an UPDATE
message with a new receipt for a payment to prolong the session.
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 Section 6.1. In this case, the Merchant posts
a Payment Request to the Payment 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
Jennings, et al. Expires January 9, 2008 [Page 15]
Internet-Draft SIP Payment July 2007
upstream proxy error or a network connectivity problem 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.
6.3. Computing costs
There are three types of costs:
o initial setup costs,
o costs per second, and
o 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 or setup
costs.
For example, 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
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).
6.4. Transition Scenarios
The deployment of the mechanisms described in this document might
take place incrementally. This section provides some information
about two likely transition scenarios: Merchant Proxy and Customer
Proxy.
6.4.1. Merchant Proxy
In this scenario, the Customer places a call to a Merchant where the
Merchant's UAS does not implement this mechanism. The Merchant's
Proxy acts on behalf of the Merchant. The key difference here is
that the Merchant's proxy must use SAML URI references instead of
SAML assertions and an extra step must be taken by the Proxy to
validate the URI reference with the Payment Provider.
Note: Many of the normal steps in a SIP call flow have been left out
of this example to focus on the pertinent items.
Jennings, et al. Expires January 9, 2008 [Page 16]
Internet-Draft SIP Payment July 2007
Customer Merchant Proxy Payment Provider Merchant
| | | |
| INVITE F1 | | |
|--------------->| | |
| 402+Payment Offer F2 | |
|<---------------| | |
| | | |
| Request for Payment F3 | |
|-------------------------------->| |
| Receipt (Reference) F4 | |
|<--------------------------------| |
| | | |
| INVITE F5 | | |
| + Receipt | | |
|----------------> | |
| 180 F6 | | |
|<---------------| | |
| | Reference F7 | |
| |--------------->| |
| | Assertion F8 | |
| |<---------------| |
| | INVITE F9 |
| |-------------------------------->|
| | 200 F10 |
| 200 F11 |<--------------------------------|
|<---------------| | |
F1 INVITE: Customer -> Merchant Proxy
The Customer sends a SIP INVITE which arrives at the Merchant's
Proxy.
F2 402 + Payment Offer: Merchant Proxy -> Customer
The Merchant's Proxy, acting on behalf of the Merchant, sends a 402
response with a Payment Offer back to the Customer. The Payment
Offer must indicate that the Payment Provider must provide a URI
reference rather than a SAML assertion as a Receipt.
F3 Request for Payment: Customer -> Payment Provider
Based on the contents of the Payment Offer, the Customer makes a
Request for Payment to one of the specified Payment Providers. The
Request for Payment specifies that the Payment Provider should return
a URI reference.
F4 Receipt (Artifact): Payment Provider -> Customer
Jennings, et al. Expires January 9, 2008 [Page 17]
Internet-Draft SIP Payment July 2007
The Payment Provider transfers the appropriate funds to the
Merchant's account and returns a URI reference to the Customer.
F5 Invite + Receipt: Customer -> Merchant Proxy
The Customer inserts a new header containing the URI reference into
the INVITE request.
F6 180: Merchant Proxy -> Customer
The Merchant Proxy immediately sends a 180 response to the Customer
indicating that the Receipt is being validated with the Payment
Provider.
F7 URI Reference: Merchant Proxy -> Payment Provider
The Merchant Proxy, acting on behalf of the Merchant, requests the
SAML assertion from the Payment Provider by providing the URI
reference.
F8 Assertion: Payment Provider -> Merchant Proxy
The SAML assertion is returned to the Merchant Proxy.
F9 INVITE: Merchant Proxy -> Merchant
Since the SAML assertion was valid, and was not used before by this
Merchant, the Merchant Proxy forwards the INVITE request to the
Merchant.
6.4.2. Customer Proxy
In this example, the Customer endpoint does not implement this
payment mechanism so the Customer's Edge Proxy acts on behalf of the
Customer. Note that the Merchant's Proxy has been left out of the
example.
Jennings, et al. Expires January 9, 2008 [Page 18]
Internet-Draft SIP Payment July 2007
Customer Customer Proxy Payment Provider Merchant
| | | |
| INVITE F1 | | |
|--------------->| | |
| 100 F2 | | |
|<---------------| INVITE F3 |
| |------------------------------------->|
| | 402+Payment Offer F4 |
| |<-------------------------------------|
| | | |
| | Request Payment F5 | |
| |-------------------->| |
| |Receipt(Reference)F6 | |
| |<--------------------| |
| | | |
| | INVITE+Receipt F7 |
| |------------------------------------->|
| | | 180 F8 |
| |<-------------------------------------|
| 180 F9 | | |
|<---------------| | |
| | | Reference F10 |
| | |<---------------|
| | | Assertion F11 |
| | |--------------->|
| | | |
| | |200 F12 |
| |<-------------------------------------|
| 200 F13 | | |
|<---------------| | |
F1 INVITE: Customer -> Customer Proxy
The Customer sends an INVITE to the Customer's Edge Proxy (in the
same administrative domain as the Customer).
F2 100: Customer Proxy -> Customer
The Customer's Proxy sends a 100 response to the Customer in order to
quench retransmissions.
F3 INVITE: Customer Proxy -> Merchant
The Customer's Proxy forwards the request to the Merchant. In most
cases, the Merchant will also have a Proxy but this has not been
indicated in this example.
Jennings, et al. Expires January 9, 2008 [Page 19]
Internet-Draft SIP Payment July 2007
F4 402 + Payment Offer: Merchant -> Customer Proxy
The Merchant sends back a 402 response with a Payment Offer to the
Customer's Proxy.
F5 Request Payment: Customer Proxy -> Payment Provider
The Customer Proxy, acting on behalf of the Customer, makes a Request
for Payment to the selected Payment Provider specifying that a URI
reference is to be returned. It is assumed that the Customer's Proxy
would have the payment credentials and Payment Provider preferences
for the Customer.
F6 Receipt (URI Reference): Payment Provider -> Customer Proxy
The Receipt is returned as a URI reference.
F7 INVITE + Receipt: Customer Proxy -> Merchant
The Customer Proxy now inserts the URI reference as a SIP header in
the INVITE request to be sent to the Merchant.
F10 Artifact: Merchant -> Payment Provider
The Merchant pulls the URI reference from the INVITE and sends a
request to the specified Payment Provider to return the SAML
assertion.
F11 Assertion: Payment Provider -> Merchant
When the SAML assertion is verified, the Merchant completes the call
and sends a 200 OK response.
6.5. Payment Provider Behavior
The primary function of the Payment Provider is to receive Requests
for Payments over HTTPS, to transfer the currency from one account to
another one, and to return a Receipt over HTTPS.
A Payment Provider MUST support TLS to offer channel security (with
integrity, replay and confidentiality protection).
When a Payment 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 presented credentials are correct for the given account.
If either the account is invalid or the authentication of the
account holder was not succesfull then an error message MUST be
Jennings, et al. Expires January 9, 2008 [Page 20]
Internet-Draft SIP Payment July 2007
returned. The procedure for responding with error responses is
described in the respective SAML specifications and the Payment
Provider MUST respect the SAML specific message processing
handling.
2. it MUST validate that the currency is acceptable by the Merchant
3. it MUST ensure that the Customer has sufficient funds, and
4. it MUST verify that the account identifier of the Merchant
corresponds to a valid account.
5. it MUST create a Receipt as a SAML assertion (or a URI reference)
by setting the corresponding fields in the assertion.
6. it MUST set the Date to the current time.
7. it MUST digitally sign the assertion.
8. it MUST transfer the money from the customer's account to the
merchant's account.
9. it MUST return either the assertion or the Artifact back to the
payment requesting entity (depending on the request).
6.6. Merchant Fetching Public Key
The Merchant needs to be able to fetch the Payment Provider's public
key. This MAY be done by an HTTPS request to a URI provided by the
Payment Service Provider. The Merchant MAY use some standard online
certificate revocation mechanism to protect against the private key
being compromised. Note that the Payment Provider may wish to use
signing certificates that are only valid for a short period of time.
The duration should be determined by the Payment Provider based on
the amount of money at risk.
7. SIP Extensions
7.1. Update response code 402
This document updates the 402 response code in RFC 3261 [7] to mean
that "A Payment is Required". Other mechanisms are used to indicate
what type of payment is required. In this specification, 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 a 402 response code.
8. Syntax
8.1. Payment Offer
The Payment Offer contains a list of costs and a list of Payment
Providers. The Customer can choose to pay any one of the provided
costs and can choose any one of the Payment Providers to use, as long
Jennings, et al. Expires January 9, 2008 [Page 21]
Internet-Draft SIP Payment July 2007
as the Payment Provider 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 Provider.
A simple example is provided with a single charge for a single
Payment Provider where the initial cost is $0.25 and the charge is
0.06/minute charged in 6 second increments.
Jennings, et al. Expires January 9, 2008 [Page 22]
Internet-Draft SIP Payment July 2007
<PaymentOffer
xmlns="urn:ietf:params:xml:ns:charge"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<payCharge>
<chargeData merchantBits="MDE1Mw=="
expiry="2005-02-28T23:20:50.52Z"/>
<costs>
<cost costPerUnitTime="6"
initialCost="250"
timeUnitSize="6000">
<currency currency="USD"
currencyDivisor="1000"
namespace="ISO.4217"/>
</cost>
</costs>
</payCharge>
<paymentServiceProviders>
<paymentServiceProvider
serviceUrl="https://psp.example.com/paymentService"
merchantId="15">
<currencies>
<currency currency="USD"
currencyDivisor="1000"
namespace="ISO.4217"/>
</currencies>
</paymentServiceProvider>
</paymentServiceProviders>
</PaymentOffer>
Figure 11: Payment Offer Example
The XML schema of the PaymentOffer corresponding to the instance
document shown in Figure 11 can be found in Section 10.1.
8.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 Provider, the
RequestForPayment is constructed as a SAML Request. The Request for
Payment consists of four components:
o The OfferData is copied from the Payment Offer from the Merchant.
o The PaymentServiceProviderData is selected from the possible
Payment Providers by the Customer.
Jennings, et al. Expires January 9, 2008 [Page 23]
Internet-Draft SIP Payment July 2007
o The amount that needs to be payed.
o Additionally, the Customer might provide authentication
credentials as part of the SAML request.
Note that it is up to the Customer to select a currency.
The OfferData consists of the following fields from the Payment
Request: offerExpiry and merchantBits.
The PaymentServiceProviderData is copied from the chosen Payment
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
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 Provider and the customerAuth is the authentication
credentials.
The SAML Request MUST be TLS protected. Authentication of the client
MUST be provided, either as part of the TLS handshake or using SAML
specific mechanisms.
The XML schema of the Payment Request is shown in Section 10.
Below is an example 'Payment Request' based on the previous 'Offer'
example with a payment of $0.30.
The following XML instance document shows a AuthnRequest that was
extended to carry the parameters for a payment request.
Jennings, et al. Expires January 9, 2008 [Page 24]
Internet-Draft SIP Payment July 2007
<?xml version="1.0" encoding="UTF-8"?>
<AuthnRequest
xmlns="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:sippay="urn:ietf:params:xml:ns:sippay"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ForceAuthn="true"
AssertionConsumerServiceURL="http://www.example.com/"
AttributeConsumingServiceIndex="0"
ProviderName="string"
ID="abe567de6"
Version="2.0"
IssueInstant="2005-02-28T22:20:51.52Z"
Destination="http://www.psp.example.com/">
<Extensions>
<PaymentRequest xmlns="urn:ietf:params:xml:ns:sippay">
<chargeExpiry> 2005-02-01T13:40:26.52Z </chargeExpiry>
<merchantBits> MDE1Mw== </merchantBits>
<merchantId> 15 </merchantId>
<serviceUrl>
https://psp.example.com/paymentService
</serviceUrl>
<currencyDivisor> 1000 </currencyDivisor>
<currency> USD </currency>
<customerId> joe </customerId>
<amount> 300 </amount>
</PaymentRequest>
</Extensions>
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
joe@example.com </saml:NameID>
</saml:Subject>
</AuthnRequest>
Figure 12: Request for Payment Example
The XML schema of the PaymentRequest corresponding to the instance
document shown in Figure 12 can be found in Section 10.2.
8.3. Payment Receipt
A SAML assertion or a reference to a SAML assertion is returned, as a
Receipt, in response to the Request for Payment. The SAML assertion
or the URI reference to a SAML assertion is included in the SIP
Jennings, et al. Expires January 9, 2008 [Page 25]
Internet-Draft SIP Payment July 2007
message in the reINVITE from the UAC.
The following example receipt is returned from the Payment Provider
and corresponds to a Receipt for a payment of $0.30.
<?xml version="1.0" encoding="UTF-8"?>
<Response
xmlns="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:payattr="urn:ietf:params:xml:ns:payattr"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="abe567de6"
InResponseTo="example-ncname"
Version="2.0"
IssueInstant="2005-01-31T12:00:00Z"
Destination="http://psp.example.com"
Consent="http://www.example.com/">
<Status>
<StatusCode Value="Success"/>
<StatusMessage>Success</StatusMessage>
<StatusDetail/>
</Status>
<!-- SAML ASSERTION AND STATEMENTS -->
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0"
ID="abcd"
IssueInstant="2005-01-31T12:00:00Z">
<saml:Issuer> www.payment-provider.com </saml:Issuer>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
joe@example.com </saml:NameID>
</saml:Subject>
<saml:Conditions
NotBefore="2005-01-31T12:00:00Z"
NotOnOrAfter="2005-01-31T12:00:00Z"/>
<saml:AuthnStatement
AuthnInstant="2005-01-31T12:00:00Z"
SessionIndex="67775277772">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute
Jennings, et al. Expires January 9, 2008 [Page 26]
Internet-Draft SIP Payment July 2007
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:ietf:params:xml:ns:payattr">
<saml:AttributeValue
xsi:type="payattr:PaymentReceiptValueType"
payattr:merchantBits="MDE1Mw=="
payattr:merchantId="15"
payattr:pspBits="abc"
payattr:serviceUrl="https://psp.example.com/paymentService"
payattr:currencyNamespace="currency:namespace..."
payattr:currencyDivisor="1000"
payattr:currency="USD" payattr:amount="300"/>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</Response>
Figure 13: Payment Receipt Example
The XML schema of the PaymentReceipt corresponding to the instance
document shown in Figure 13 can be found in Section 10.3.
8.4. Refunds
Refunds share the same syntax as a 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 referenced by the serviceUrl.
The amount to refund is determined by the Merchant at the time of the
refund.
Editor's Note: Add an example here.
8.5. Verifying the Receipt
The Merchant MUST verify the signature in the Receipt by applying the
following steps:
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.
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.
Jennings, et al. Expires January 9, 2008 [Page 27]
Internet-Draft SIP Payment July 2007
9. Usage Scenarios for SIP Payment
This section shows the applicability of SIP payment for two example
scenarios.
9.1. SPAM
Payment at risk has been suggested as part of a possible solution to
SPAM in VoIP systems [16]. 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. XML Schemas
This section defines the XML schema for the protocol introduced in
this document.
10.1. PaymentOffer XML Schema
This section shows the XML schema for the PaymentOffer that the
Merchant sends to the Customer.
<schema
targetNamespace="urn:ietf:params:xml:ns:charge"
xmlns:charge="urn:ietf:params:xml:ns:charge"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<element name="PaymentOffer">
<complexType>
<sequence>
Jennings, et al. Expires January 9, 2008 [Page 28]
Internet-Draft SIP Payment July 2007
<element name="payCharge">
<complexType>
<sequence>
<element name="chargeData">
<complexType>
<attribute name="expiry"
type="dateTime"
use="required"/>
<attribute name="merchantBits"
type="base64Binary"
use="required"/>
</complexType>
</element>
<element name="costs">
<complexType>
<sequence>
<element name="cost">
<complexType>
<sequence>
<element ref="charge:currency"/>
</sequence>
<attribute name="initialCost"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="costPerUnitTime"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="timeUnitSize"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="costPerUnitData"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="dataUnitSize"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="minCost"
type="unsignedLong"
use="optional"
default="0"/>
<attribute name="maxCost"
type="unsignedLong"
use="optional"
Jennings, et al. Expires January 9, 2008 [Page 29]
Internet-Draft SIP Payment July 2007
default="0"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="paymentServiceProviders">
<complexType>
<sequence>
<element name="paymentServiceProvider">
<complexType>
<sequence>
<element name="currencies">
<complexType>
<sequence>
<element ref="charge:currency"/>
</sequence>
</complexType>
</element>
</sequence>
<attribute name="url"
type="anyURI"
use="optional"/>
<attribute name="serviceUrl"
type="anyURI"
use="required"/>
<attribute name="merchantId"
type="unsignedLong"
use="required"/>
<attribute name="pspBits"
type="base64Binary"
use="optional"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="currency">
<complexType>
<attribute name="namespace"
type="string"
use="required"/>
Jennings, et al. Expires January 9, 2008 [Page 30]
Internet-Draft SIP Payment July 2007
<attribute name="currency"
type="string"
use="required"/>
<attribute name="currencyDivisor"
type="unsignedLong"
use="required"/>
</complexType>
</element>
</schema>
PaymentOffer XML Schema
10.2. Payment Request
This section shows the XML schema for the PaymentRequest that is used
inside the SAML AuthnRequest request message.
Jennings, et al. Expires January 9, 2008 [Page 31]
Internet-Draft SIP Payment July 2007
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:sippay"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sippay="urn:ietf:params:xml:ns:sippay">
<xs:element name="PaymentRequest"
type="sippay:PaymentRequestType"/>
<xs:complexType name="PaymentRequestType">
<xs:sequence>
<xs:element name="chargeExpiry"
type="xs:dateTime"
minOccurs="1" maxOccurs="1"/>
<xs:element name="merchantBits"
type="xs:base64Binary"
minOccurs="1" maxOccurs="1"/>
<xs:element name="merchantId"
type="xs:token"
minOccurs="1" maxOccurs="1"/>
<xs:element name="serviceUrl"
type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="pspBits"
type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
<xs:element name="currencyNamespace"
type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="currencyDivisor"
type="xs:unsignedLong"
minOccurs="1" maxOccurs="1"/>
<xs:element name="currency"
type="xs:token"
minOccurs="1" maxOccurs="1"/>
<xs:element name="customerId"
type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="customerBillingCode"
type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="amount"
type="xs:unsignedLong"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Payment Request XML Schema
Jennings, et al. Expires January 9, 2008 [Page 32]
Internet-Draft SIP Payment July 2007
10.3. Payment Receipt
This section defines the XML schema for the Payment Receipt that is
used in the SAML Response message returned after a successful
processing of the SAML AuthnRequest.
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:payattr"
xmlns:payattr="urn:ietf:params:xml:ns:payattr"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="2.0">
<annotation>
<documentation>
Document identifier:
payment-receipt-schema
Location:
http://www.tschofenig.com/svn/draft-jennings-sipping-pay/Schema/
Revision history: V1.0
(June, 2006): Custom schema for SIP Payment attribute profile.
</documentation>
</annotation>
<complexType name="PaymentReceiptValueType">
<simpleContent>
<extension base="anyURI">
<attribute ref="payattr:merchantBits"
use="required"/>
<attribute ref="payattr:merchantId"
use="required"/>
<attribute ref="payattr:pspBits"
use="required"/>
<attribute ref="payattr:serviceUrl"
use="required"/>
<attribute ref="payattr:currencyNamespace"
use="required"/>
<attribute ref="payattr:currencyDivisor"
use="required"/>
<attribute ref="payattr:currency"
use="required"/>
<attribute ref="payattr:amount"
use="required"/>
</extension>
</simpleContent>
</complexType>
Jennings, et al. Expires January 9, 2008 [Page 33]
Internet-Draft SIP Payment July 2007
<attribute name="merchantBits" type="base64Binary"/>
<attribute name="merchantId" type="token" />
<attribute name="pspBits" type="string" />
<attribute name="serviceUrl" type="anyURI" />
<attribute name="currencyNamespace" type="token"/>
<attribute name="currencyDivisor" type="unsignedLong" />
<attribute name="currency" type="token"/>
<attribute name="amount" type="unsignedLong"/>
</schema>
Payment Receipt XML Schema
11. HTTP Binding
This section defines an HTTP [10] binding for the protocol between
the Customer and the Payment Provider, which all conforming
implementations MUST support.
The three request messages are carried in this binding as the body of
an HTTP POST request. The MIME type of both request and response
bodies should be "application/xml", except that a SAML assertion
SHOULD have the MIME type "application/samlassertion+xml".
The Payment Provider SHOULD populate the HTTP headers so that they
are consistent with the contents of the message. In particular, the
"Expires" and cache control headers SHOULD be used to control the
caching of any SAML assertion. The HTTP status code SHOULD have the
same first digit as any "contextResponse" or "error" body included,
and it SHOULD indicate a 2xx series response when a SAML assertion is
included.
This binding also includes a default behaviour, which is triggered by
a GET request, or a POST with no request body. In this case, the
Payment Provider MUST attempt to provide a SAML assertion.
This binding MUST use TLS as described in [8]. TLS provides message
integrity and confidentiality between the Customer and the Payment
Provider. The Payment Provider MUST use server-side authentication.
Client authentication can either be provided as part of the TLS
handshake or using HTTP specific mechanisms.
12. Security Considerations
The security properties of the proposed protocol depends on the
security of the communication between the three parties. The
following threats and countermeasures have been considered:
Jennings, et al. Expires January 9, 2008 [Page 34]
Internet-Draft SIP Payment July 2007
12.1. Stolen Assertion
Threat:
An adversary can eavesdrop on the communication between the
Customer and the Payment Provider and between the Customer and the
Merchant and thereby learn the SAML assertion (Receipt). The
adversary could use this assertion to request a service from the
Merchant on behalf of the legitimate Customer.
Countermeasures:
Two countermeasures are provided to deal with this treat. The
communication between the Customer and the Payment Provider must
be confidentiality, integrity and replay protected. The
communication between the Customer and the Merchant SHOULD
experience hop-by-hop protection (e.g., TLS in a hop-by-hop
fashion between the Customer, SIP proxies and the Merchant) and
end-to-end security using the SIP Identity mechanism.
Furthermore, the content of the requested SAML assertion contains
statements that prevent reusage of the SAML assertion in other
contexts. The Offer, for example, provides a merchantBits value
that allows the Merchant to match the Offer to the Receipt. The
identities of the Customer and the Merchant are included in the
Receipt and the lifetime might be limited.
12.2. MitM Attack
Threat:
Since the SAML assertion is carried within a SIP message sent by
the Customer towards the Merchant an intermedidate SIP proxy could
use the assertion in order to impersonate the user towards the
Merchant in future protocol sessions.
Countermeasures:
This document does not assume that the assertion is bound to a
symmetric or an asymmetric key although SAML provides this
capability using the holder-of-the-key concept. If there is no
such holder-of-the-key concept utlized with the assertion then
only the content of the assertion can be used to prevent replay
attacks and man-in-the-middle attacks. Similarly to the threat
described in Section 12.1 the content of the assertion limits its
usage to particular endpoints, potentially for a particular
duration, for a particular service and for certain amount of time.
Jennings, et al. Expires January 9, 2008 [Page 35]
Internet-Draft SIP Payment July 2007
12.3. Forged Assertion
Threat:
A malicious Customer or a malicious intermediate SIP proxy could
forge or alter a SAML assertion in order to communicate with the
Merchant to lead to unexpected behavior or even to refunding to a
preselected account.
Countermeasures:
To avoid this kind of attack, the Payment Provider must assure
that proper mechanisms for protecting the SAML assertion is
provided. It is RECOMMENDED to protect the assertion using a
digital signature.
12.4. Replay Attack
Threat:
An adversary might eavesdrop an assertion in order to later replay
it to gain access to resources (e.g., to access a SIP service).
Countermeasures:
When the Customer transmits a SIP message that requires payment
then the Merchant creates an Offer that contains a merchantBits
value. The Offer will be used by the Customer to obtain an
assertion by the Payment Provider and will again be presented to
the Merchant. The Merchant is therefore able to determine whether
the merchantBits is still valid and that it can be associated with
an Offer. The Offer is only valid for a certain time. Timestamp
information carried inside the assertion might also indicate a
validity timeframe.
13. IANA Considerations
13.1. Payment-Receipt Header
Add the following entry to the header sub-registry.
Header Name compact Reference
----------------- ------- ---------
Payment-Receipt [RFCXXXX]
Jennings, et al. Expires January 9, 2008 [Page 36]
Internet-Draft SIP Payment July 2007
13.2. 402 Response
Add the following entry to the response code sub-registry under the
"Request Failure 4xx" heading.
402 Payment Required [RFCXXXX]
13.3. charge+xml
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:
Hannes Tschofenig Hannes.Tschofenig@siemens.com;
Intended usage: COMMON
Author/Change controller:
the IESG
Jennings, et al. Expires January 9, 2008 [Page 37]
Internet-Draft SIP Payment July 2007
13.4. IANA Registration for the SIP SAML Header
The SAML header is created by this document, with its definition and
rules in Section 5 of this document.
13.5. IANA Registration for Two New SIP Option Tags
Two new SIP option tags are created by this document, "SAML" and
"Unknown-SAML", with the definitions and rules for each in Section 5
of this document.
13.6. IANA Registration for Response Code 4XX
Reference: RFC-XXXX (i.e., this document)
Response code: 424
Default reason phrase: Bad SAML Information
The 'application/samlassertion+xml' URN sub-namespace and Content-
type is already registered by IANA (see [11]).
14. Acknowledgments
The authors would like to thank James Polk and Brian Rosen for their
work with SIP Location Conveyance. Text from their draft was reused
in this document due to the perceived similarity of the mechanisms.
15. References
15.1. Normative References
[1] Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-02 (work in progress), May 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", OASIS
SSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01,
April 2005.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[5] Jennings, C., "Certificate Management Service for The Session
Jennings, et al. Expires January 9, 2008 [Page 38]
Internet-Draft SIP Payment July 2007
Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in
progress), March 2007.
[6] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[7] 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.
[8] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[11] OASIS Security Services Technical Committee (SSTC),
"application/samlassertion+xml MIME Media Type Registration",
IANA MIME Media Types Registry application/samlassertion+xml,
December 2004.
[12] International Organization for Standardization, "Codes for the
representation of currencies and funds", ISO Standard 4217,
2001.
15.2. Informational References
[13] Burdett, D., "Internet Open Trading Protocol - IOTP Version
1.0", RFC 2801, April 2000.
[14] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[15] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", RFC 4028, April 2005.
[16] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol
(SIP) and Spam", draft-ietf-sipping-spam-04 (work in progress),
February 2007.
[17] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
Jennings, et al. Expires January 9, 2008 [Page 39]
Internet-Draft SIP Payment July 2007
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
Jason Fischl
CounterPath Solutions, Inc.
Suite 300, One Bentall Centre, 505 Burrard Street
Vancouver, BC V7X 1M3
Canada
Phone: +1 604 320-3340
Email: jason@counterpath.com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Gyuchang Jun
Bitpass, Inc.
3300 Hillview Avenue, Suite 165
Palo Alto, CA 94304
USA
Phone: 650 354-1882
Jennings, et al. Expires January 9, 2008 [Page 40]
Internet-Draft SIP Payment July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jennings, et al. Expires January 9, 2008 [Page 41]
| PAFTECH AB 2003-2026 | 2026-04-22 23:01:33 |