idnits 2.17.1 draft-jennings-sipping-pay-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1789. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 474 has weird spacing: '... Rr ar ...' == Line 478 has weird spacing: '... Rr ar ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1582 -- Looks like a reference, but probably isn't: 'RFC3023' on line 1599 == Unused Reference: '12' is defined on line 1691, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1710, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-sip-saml (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 4474 (ref. '4') (Obsoleted by RFC 8224) == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-03 ** Obsolete normative reference: RFC 2818 (ref. '8') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2246 (ref. '9') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (ref. '10') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Obsolete informational reference (is this intentional?): RFC 1305 (ref. '14') (Obsoleted by RFC 5905) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-spam-04 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Fischl 5 Expires: January 9, 2008 CounterPath Solutions, Inc. 6 H. Tschofenig 7 Siemens Networks GmbH & Co KG 8 G. Jun 9 Bitpass, Inc. 10 July 8, 2007 12 Payment for Services in Session Initiation Protocol (SIP) 13 draft-jennings-sipping-pay-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 9, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Service usage might require some form of compensation and this is 47 also true for many communication systems where an entity receiving a 48 call should be able to charge the caller. This is necessary for 49 allowing fair communication between two communicating parties and is 50 a major strategy for reducing the viability of SPAM. This draft 51 proposes an approach for doing this in SIP using the Security 52 Assertion Markup Language (SAML). It relies on a third party to act 53 as a payment provider and is designed for low value transactions. It 54 does not aim to provide the same capability as other authentication, 55 authorization and accounting backend infrastructures. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. SAML Payment Scenario using Assertions . . . . . . . . . . 4 61 1.2. SAML Payment Scenario using URI References . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Requirements, Assumptions and Goals . . . . . . . . . . . . . 9 64 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Extended SIP SAML Profile . . . . . . . . . . . . . . . . . . 10 66 5.1. New Option Tags and a SAML Header Created . . . . . . . . 10 67 5.2. 424 (Bad SAML Information) Response Code . . . . . . . . . 13 68 6. SIP Payment Protocol . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. UAC Behavior (Customer) . . . . . . . . . . . . . . . . . 13 70 6.2. UAS Behavior (Merchant) . . . . . . . . . . . . . . . . . 14 71 6.3. Computing costs . . . . . . . . . . . . . . . . . . . . . 16 72 6.4. Transition Scenarios . . . . . . . . . . . . . . . . . . . 16 73 6.4.1. Merchant Proxy . . . . . . . . . . . . . . . . . . . . 16 74 6.4.2. Customer Proxy . . . . . . . . . . . . . . . . . . . . 18 75 6.5. Payment Provider Behavior . . . . . . . . . . . . . . . . 20 76 6.6. Merchant Fetching Public Key . . . . . . . . . . . . . . . 21 77 7. SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21 78 7.1. Update response code 402 . . . . . . . . . . . . . . . . . 21 79 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 8.1. Payment Offer . . . . . . . . . . . . . . . . . . . . . . 21 81 8.2. Request for Payment . . . . . . . . . . . . . . . . . . . 23 82 8.3. Payment Receipt . . . . . . . . . . . . . . . . . . . . . 25 83 8.4. Refunds . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 8.5. Verifying the Receipt . . . . . . . . . . . . . . . . . . 27 85 9. Usage Scenarios for SIP Payment . . . . . . . . . . . . . . . 28 86 9.1. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 9.2. Micro Billing . . . . . . . . . . . . . . . . . . . . . . 28 88 10. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 10.1. PaymentOffer XML Schema . . . . . . . . . . . . . . . . . 28 90 10.2. Payment Request . . . . . . . . . . . . . . . . . . . . . 31 91 10.3. Payment Receipt . . . . . . . . . . . . . . . . . . . . . 33 92 11. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 94 12.1. Stolen Assertion . . . . . . . . . . . . . . . . . . . . . 35 95 12.2. MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 35 96 12.3. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 36 97 12.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 36 98 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 99 13.1. Payment-Receipt Header . . . . . . . . . . . . . . . . . . 36 100 13.2. 402 Response . . . . . . . . . . . . . . . . . . . . . . . 37 101 13.3. charge+xml . . . . . . . . . . . . . . . . . . . . . . . . 37 102 13.4. IANA Registration for the SIP SAML Header . . . . . . . . 38 103 13.5. IANA Registration for Two New SIP Option Tags . . . . . . 38 104 13.6. IANA Registration for Response Code 4XX . . . . . . . . . 38 105 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 106 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 108 15.2. Informational References . . . . . . . . . . . . . . . . . 39 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 110 Intellectual Property and Copyright Statements . . . . . . . . . . 41 112 1. Introduction 114 Service usage might require some form of compensation and this is 115 also true for many communication systems where an entity receiving a 116 call should be able to charge the caller. This is necessary for 117 allowing fair communication between two communicating parties and is 118 a major strategy for reducing the viability of SPAM. This draft 119 proposes an approach for doing this in SIP using the Security 120 Assertion Markup Language (SAML). It relies on a third party to act 121 as a payment provider and is designed for low value transactions. It 122 does not aim to provide the same capability as other authentication, 123 authorization and accounting backend infrastructures. 125 This document creates SAML profiles and bindings in addition to those 126 specified in [1]. Although this document provides a very specific 127 usage scenario for SAML usage within SIP it is written in a generic 128 way to support other usage scenarios following the same communication 129 pattern. This approach is inline with the idea of SAML. The 130 abstract model allows a SAML assertion or an URI reference to a SAML 131 assertion to be requested from a trusted third party via HTTP. The 132 SAML assertion or URI reference is returned to the requesting party. 133 Then, it is conveyed in SIP to another party that is performing an 134 authorization decision based on the received information. To resolve 135 a URI reference into a SAML assertion it is additionally necessary to 136 contact the trusted third party using HTTP (see [1]). 138 Section 1.1 shows the basic message exchange using SAML assertions 139 and Section 1.2 shows a variation with URI references to SAML 140 assertions. Both message exchanges show the high-level SIP payment 141 interaction where three parties are involved: 142 o a consumer who is the caller (or SAML requester), 143 o a merchant who is the person being called (or SAML responder), 144 o and the Payment Provider (or SAML Authority). 146 1.1. SAML Payment Scenario using Assertions 147 P C M 148 | | 1) Call | 149 | |------------------------>| 150 | | | 151 | | 2) 402 + Payment Offer | 152 | 3) Request for |<------------------------| 153 | a Payment | | 154 |<-------------------------| | 155 | | | 156 | 4) SAML Assertion | | 157 | (=Receipt) | | 158 |------------------------->| | 159 | | 5) Call + Receipt | 160 | |------------------------>| 161 | | | 162 | | 6) 200 OK | 163 | |<------------------------| 164 | | | 166 Figure 1: Overview for SAML Assertion Handling 168 The Customer (C) and the Merchant (M) interact with each other using 169 SIP and the Customer uses HTTP to exchange messages with the Payment 170 Provider (P). Initially, C makes a call to M (1). M determines that 171 a payment is required and includes information about the payment in 172 an Offer body of a 402 (Payment Required) response to C (2). C looks 173 at this Offer and decides to make a payment. The Customer instructs 174 its Payment Provider to make a transfer from the Customer's account 175 to the Merchants's account (3) using a request for a SAML assertion 176 with the extensions defined in this document. The Payment Provider 177 returns a receipt for this transfer (4). This receipt is a SAML 178 assertion. C resubmits the call to M but this time provides the 179 Receipt for the transaction (5). If the authorization was 180 successful, M determines whether the Receipt is valid (by checking 181 the digital signature and the content of the assertion) and continues 182 with the call processing. 184 The Offer contains information about the parties P, that are 185 acceptable to M, the amount of the transaction, the account 186 identifier for M at P, and random data (carried in the merchantBits 187 field) to make it easier for M to avoid replay attacks. C includes 188 this information when making the Request for Payment to P; adds its 189 own account information and authorization password; and sends this to 190 P, which produces a Receipt for the transaction if it is successful. 191 This transfer from C to P is made across an encrypted, integrity 192 protected channel. The Receipt includes a timestamp when P made the 193 transaction and protects the Receipt with a digital signature. C 194 resubmits the call to M with the Receipt from P. M can check for 195 replay attacks using the timestamp and the merchantBits initially 196 provided with the Offer. M can then check the signature is valid 197 using P's public key. 199 1.2. SAML Payment Scenario using URI References 201 This section shows a variation of the message exchange presented in 202 Section 1.1 with the difference that C requests a URI reference 203 rather than an assertion (see message 3). The Payment Provider 204 creates a SAML assertion after authentication and authorization and 205 crafts a URI reference that points to it, which is then returned to C 206 as part of a successful response message (see message 4). This URI 207 reference is then forwarded to M in message 5. When M wants to 208 resolve the URI reference to an assertion it uses the 'SIP SAML URI- 209 based Assertion Fetch Profile' described in Section 6.1 of [1]. This 210 exchange is shown in message 6 and 7. The receipt is carried in a 211 SIP header. 213 P C M 214 | | 1) Call | 215 | |------------------------>| 216 | | | 217 | | 2) 402 + Payment Offer | 218 | 3) Request for |<------------------------| 219 | a Payment | | 220 |<-------------------------| | 221 | | | 222 | 4) SAML URI Reference | | 223 | (=Receipt) | | 224 |------------------------->| | 225 | | 5) Call + Receipt | 226 | |------------------------>| 227 | | | 228 | 6) HTTP URI Resolution | 229 |<---------------------------------------------------| 230 | | | 231 | 7) HTTP/1.1 200 OK & Assertion | 232 |----------------------------------------------------| 233 | | | 234 | | 8) 200 OK | 235 | |<------------------------| 236 | | | 238 Figure 2: Overview for SAML URI Reference Handling 240 Figure 1 and Figure 2 do not show the interaction between the 241 Merchant and the Customer if refunding is necessary. Additionally, 242 the interaction between the Merchant and the Payment Provider to 243 reconcile is not shown in these two figures. Further message 244 exchanges that are shown as transition scenarios (see Section 6.4) 245 finish the message exchange. 247 The proposal described in this document does not aim to provide 248 functionality equivalent to AAA protocols. For example, there is no 249 guarantee or recourse if M does not provide the service after C 250 transfers money into M's account. The system is designed for low 251 value transactions in which, if M cheats, C can choose to never deal 252 with M again but the value of the transaction is lost. This scheme 253 is designed for systems whereby the communication between M and C and 254 the communication between C and P can be executed in real time. 255 While it is possible to develop schemes that deal with some of these 256 problems, Payment Providers deploying them have not been willing to 257 provide services for transaction fees on the order of one US cent. 258 The authors believe that the simplified scheme presented here will 259 make it easier to reach these low value transactions. 261 2. Terminology 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in RFC 2119 [2]. 267 This work adopts the terminology from the framework in RFC 2801 [13]. 269 Additionally, the following terms are used: 271 Customer: 273 The entity that is paying for the call, typically the SIP User 274 Agent Client (UAC) or a proxy in the same administrative domain as 275 the UAC. 277 Merchant: 279 The entity wishing to be paid for the call, typically the SIP User 280 Agent Server (UAS) or a proxy in the same administrative domain as 281 the UAS. 283 Payment Provider: 285 The third party that handles the transfer of funds from Customer 286 to Merchant. The Internet Open Trading Protocol (IOTP) [13] 287 refers to this as the Brand. 289 Offer: 291 The information sent from the Merchant to the Customer describing 292 what payment is needed. 294 Request for Payment: 296 The information sent from the Customer to the Payment Provider 297 describing the transfer of currency needed. This request is 298 implemented as a request for a SAML assertion. 300 Receipt: 302 The information sent from the Payment Service Provider to the 303 Customer and passed on to the Merchant. The Receipt is either a 304 SAML assertion or a URI reference to a SAML assertion. The 305 Receipt tells the Customer that the payment transaction was 306 successfully completed (if either a SAML assertion or a SAML URI 307 reference is returned). The Merchant receives an assurance that 308 the transaction was successful after receiving the Receipt and 309 verifying it succesfully. 311 Currency: 313 Could be a classical currency such as the Euro or US Dollar or 314 could be a pseudo currency such as airline mileage points. 316 Assertion: 318 An assertion is an XML document that contains authentication 319 statements, attribute statements and authorization decision 320 statements. In an authentication statement, an issuing authority 321 asserts that a certain subject was authenticated by certain means 322 at a certain time. In an attribute statement, an issuing 323 authority asserts that a certain subject is associated with 324 certain attributes which has certain values. In an authorization 325 decision statement, a certain subject with a certain access type 326 to a certain resource has given certain evidence that the identity 327 is correct. The assertion is digitally signed to protect it 328 against unwanted modifications by third parties. 330 HTTP-based SAML URI Reference: 332 The SAML URI Binding specifies a means by which SAML assertions 333 can be referenced by URIs and thus be obtained through resolution 334 of such URIs. These references point to a server that temporarily 335 stores an assertion. An advantage of SAML URI Bindings is that 336 they may be placed into a SIP header by intermediate SIP proxy 337 elements. 339 For further terminology related to SAML the reader is referred to 340 [3]. 342 3. Requirements, Assumptions and Goals 344 This section lists some basic requirements and goals for the protocol 345 presented in this document. This document extends the SIP SAML 346 profile and binding described in [1] and describes a usage scenario 347 utilizing these extensions, namely SIP payment. The goals and 348 assumptions below refer to the application of SAML usage for SIP 349 payment. 351 o Provide a system for callers to pay the person they are calling 352 using a 3rd party clearing house. A trust relationship between 353 the Merchant and the Payment Provider and between the Customer and 354 the Payment Provider must exist. The Customer must be able to 355 authenticate itself to the Payment Provider and to instruct the 356 Payment Provider to transfer money from its account to another 357 account (i.e., the account of the Merchant). It is not necessary 358 for the Customer and Merchant to have a direct relationship with 359 each other. The Payment Provider acts as a clearinghouse. 360 o The protocol must support multiple currencies and must offer the 361 ability for the Customer to learn the price before initiating a 362 transaction. 363 o Support various billing models including: flat rate, per unit 364 time, per unit data 365 o The solution must be cost effective for low cost transactions. 366 o The solution must allow Customers to remain anonymous towards the 367 Merchants. 368 o Support for a simple refund mechanism must be provided. 370 4. Non-Goals 372 There needs to be a mechanism for Customers and Merchants to enroll 373 and transfer money in and out of their accounts. The mechanisms to 374 accomplish this functionality are outside the scope of this document. 375 They can be provided by using web forms to enroll, obtain an account 376 number, and provide the typical credit card mechanism to transfer 377 money into the account. Transfers out of the account could be done 378 with the typical wire transfer mechanism to bank accounts. 380 5. Extended SIP SAML Profile 382 Several push-based SIP Request Methods are capable (and applicable) 383 of carrying a SAML assertion or URI reference, including: 384 o INVITE, 385 o REGISTER, 386 o UPDATE, and 387 o MESSAGE, 389 More than one SAML assertion or URI reference to a SAML assertion MAY 390 be included in the same message body part. 392 While the authors do not yet see a reason to have payment receipts 393 carried in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not 394 see a reason to prevent carrying a SAML assertion or a URI reference 395 within these Method Requests as long as the SIP message meets the 396 requirements stated within this document. 398 SIP end points SHOULD use SIP Identity [4] to tie the SAML assertion 399 to the SIP message end-to-end. Furthermore, in addition to the 400 protection provided by SIP Identity, the security protection 401 equivalent to SIPS SHOULD be used (i.e., channel security hop-by-hop 402 between the involved signaling entities). This ensures that 403 eavesdroppers located along the signaling path are unable to 404 eavesdrop an assertion in transit. This is mainly a mechanism to 405 ensure privacy of the transmitted information. Since SIP proxies are 406 therefore still able to see the assertion in clear it is necessary to 407 include enough information in the SAML assertion in order to prevent 408 replay attacks. For more information about replay attacks regarding 409 SAML and SIP the reader is referred to Section 9 of [1]. 411 Self-signed certificates should only be used in combination with [5] 412 for protecting a SAML assertion (or a URI reference). 414 SIP Methods such as SUBSCRIBE and NOTIFY (in combination with 415 PUBLISH) are considered a pull-based mechanism, and will be discribed 416 in a future version of this document. 418 5.1. New Option Tags and a SAML Header Created 420 This document creates and IANA registers two new option tags, "SAML" 421 or "unable-SAML". User agent clients who support this specification 422 will indicate that support by including either of these option-tags 423 in a Supported header. 425 This document also creates and IANA registers a new SAML header. The 426 SAML header, if present, will have one of three header values defined 427 by this document: 429 o a HTTP URI Reference to a SAML assertion 430 o a Content ID indicating where the SAML assertion or URI reference 431 to a SAML assertion is within the message body 432 o a SAML based option tag 434 A URI reference to a SAML assertion is a pointer to a record on a 435 remote node containing the SAML assertion. 437 If the SAML assertion is contained in a SIP message, a SAML header 438 will be present in the message with a content-ID (cid-url) [6] 439 indicating where in the message body a SAML assertion or a URI 440 reference is for this UA. This is to aid a node in not having to 441 parse the whole message body or body parts looking for this body 442 type. 444 The Unknown-SAML option tag in a SAML header indicates a UA 445 understands the concept of SAML conveyance, but does not have the 446 desired SAML assertion to provide. This can save error messages from 447 being generated looking for an answer the UA does not have to give. 448 It can also allow a processing entity the immediate knowledge it 449 needs to act as if the UA will not learn SAML on its own, and perhaps 450 call on another process to address the needs for that message. 452 The new "SAML" header has the following BNF syntax: 454 SAML = "SAML" HCOLON SAML-value *(COMMA 455 SAML-value) 456 SAML-value = (addr-spec / option-tag / token) 457 addr-spec = cid-url / absoluteURI 458 option-tag = string 459 token = token / quoted-string 460 cid-url = "cid" ":" content-id / 461 absoluteURI = SIP or SIPS-URI 462 content-id = url-addr-spec 463 url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec 465 The Content-ID (cid) is defined in [6] to locate message body parts. 467 The absoluteURI is the SIP or SIPS URI of the reference, which points 468 at a SAML of a UA in a record on a remote node. 470 The following table extends the values in Table 2/3 of RFC 3261 [7]. 472 Header field where proxy INV ACK CAN BYE REG OPT PRA 473 ---------------------------------------------------------------- 474 SAML Rr ar o - - o o o - 476 Header field where proxy SUB NOT UPD MSG REF INF PUB 477 ---------------------------------------------------------------- 478 SAML Rr ar - - o o o o - 480 The SAML header MAY be added, or read if present in a Request message 481 listed above. A proxy MAY add the SAML header in transit if one is 482 not present. [7] states message bodies cannot be added by proxies. A 483 proxy MAY read the SAML header in transit if present. 485 It is RECOMMENDED that only one SAML header be in the same message, 486 but this is not mandatory. 488 Here is an example INVITE that includes the proper SAML and Supported 489 headers (without the SAML message body part): 491 INVITE sip:bob@biloxi.example.com SIP/2.0 492 Via: SIP/2.0/TCP pc33.atlanta.example.com 493 ;branch=z9hG4bK74bf9 494 Max-Forwards: 70 495 To: Bob 496 From: Alice ;tag=9fxced76sl 497 Call-ID: 3848276298220188511@atlanta.example.com 498 SAML: cid:alice123@atlanta.example.com 499 Supported: SAML 500 Accept: application/sdp, application/samlassertion+xml 501 CSeq: 31862 INVITE 502 Contact: 503 Content-Type: multipart/mixed; boundary=boundary1 504 Content-Length: ... 506 --boundary1 508 Content-Type: application/sdp 510 ...SDP here 512 --boundary1 514 Content-Type: application/samlassertion+xml 515 Content-ID: alice123@atlanta.example.com 517 ...SAML assertion in here 518 --boundary1-- 520 The SAML header from the above INVITE: 522 SAML: cid:alice123@atlanta.example.com 524 indicates the Content-ID SAML [6] within the multipart message body 525 of were the SAML assertion is. 527 If the SAML header were this instead: 529 SAML: https://example.com/assns/?ID=abcde 531 this would indicate that a URI reference to a SAML assertion was 532 included in this message and no SAML body would be required. 534 5.2. 424 (Bad SAML Information) Response Code 536 In the case that a UAS or SIP intermediary detects an error in a 537 Request message specific to the SAML assertion supplied by-value or 538 by-reference, a new 4XX level error is created here to indicate this 539 is the problem with the request message. This document creates the 540 new error code: 542 424 (Bad SAML Information) 544 The 424 (Bad SAML Information) Response code is a rejection of the 545 SAML contents, whether by-value or by-reference of the original SIP 546 Request. The server function of the recipient (UAS or intermediary) 547 has deemed this URI reference to a SAML assertion or the SAML 548 assertion to be bad. No further action by the UAC is required. The 549 UAC can use whatever means it knows to verify/refresh its SAML 550 information before attempting a new request. There is no cross- 551 transaction awareness expected by either the UAS or SIP intermediary 552 as a result of this error message. 554 This new error code will be IANA registered in Section 13. 556 6. SIP Payment Protocol 558 6.1. UAC Behavior (Customer) 560 The UAC SHOULD indicate that it can accept the application/charge 561 MIME type in SIP requests it sends. 563 In the case where the UAC receives a 402 response containing an 564 application/charge body, it MUST check that this offer is acceptable 565 to the user of the UAC. This could be done using a policy that was 566 previously entered by the user. If the offer contains a Payment 567 Provider with which the user has an account and the offer is 568 acceptable, then the UAC sends a Request for Payment to the Payment 569 Provider. 571 The UAC needs to look at the available Payment Providers, cost, and 572 currency and select an appropriate one. The UAC MUST copy the 573 PaymentServiceProviderData fields from the offer into the Request for 574 Payment parameters. The UAC must look at the cost elements in the 575 offer to decide how large a payment the user wishes to make and set 576 the amount and currency parameters appropriately. Finally, it needs 577 to fill the CustomerData parameters. It is critical that the UAC 578 check the certificate of the HTTPS TLS connection as specified in RFC 579 2818 [8] and RFC 2246 [9]. 581 After selecting and constructing the SAML request message it is sent 582 over the HTTPS secured connection. The detailed format of the 583 request is shown in Section 10. 585 The response will be either an error, a SAML assertion or a URI 586 reference. The user needs to be informed if an error is received and 587 the transaction SHOULD NOT be retried unchanged. When a valid 588 response is received, the UAC SHOULD resubmit the SIP request that 589 caused the 402 but this time by including the Receipt (i.e., the URI 590 reference or the SAML assertion). 592 The UAC needs to compute the amount of payment it wishes to make by 593 looking at the cost information provided as part of the Offer. The 594 UAC is also responsible for determining when a new payment has to be 595 made and refreshing the call with additional payments before this 596 happens. For example, the UAC could initially decide to provide 597 enough payment for a 3 minute call. After 2.5 minutes the UAC might 598 decide to pay for an additional 3 minutes. It would do this by 599 issuing a new Payment Request to the Payment Provider for an 600 additional 3 minutes' worth of resources and then sending the new 601 receipt with a SIP Re-INVITE or UPDATE transaction to the UAS. 603 6.2. UAS Behavior (Merchant) 605 When the UAS receives a request it wishes to charge for, the UAS 606 should check whether the UAC has set the Accept header to include 607 application/charge. If it has, it MAY reject the request with a 402 608 and attach an application/charge to the response. Note that the 609 application/charge document can be attached on any failure response. 610 For example, this could allow a UAS to combine the offer with a 611 request for authorization in a 401 response. It needs to include 612 lists of all the Payment Providers that are acceptable to the UAS and 613 include the identity of the Merchant. It also needs to form a list 614 of currencies that are acceptable and what the cost in each one is. 615 The merchant may also specify a minimum cost and/or a maximum cost in 616 the offer. The costs are described in Section 6.3. 618 When the UAS receives a request that contains a Receipt (as a SAML 619 assertion) as defined in [1], the UAS MUST verify that the assertion/ 620 artifact is valid using the following steps. 621 1. Ensure that the amount of the payment is appropriate and if this 622 receipt matches to a previous Offer to prevent replay attacks. 623 2. Check that the digital signature of the Receipt is valid. This 624 includes path validation and to check that the certificate of 625 Payment Provider is still valid. 626 3. Check that the time between the payment and now is acceptably 627 low. This MUST be a configurable parameter and should default to 628 30 seconds. The UAS SHOULD support NTP RFC 1305 [14]. [Editor's 629 Note: Is this mechanism really needed?] 630 4. The UAS MUST check that this receipt has not been previous used. 631 The limited time window limits the amount of state the UAS must 632 keep to make this check. If several UASs are using the same 633 merchant-id, this replay detection needs to be done across all 634 the UASs. The OfferData can be used with opaque encrypted data 635 to help do this. 637 If the payment is accepted, it the Merchant's responsibility to end 638 the call after the amount paid becomes inadequate to cover the 639 session. The UAS SHOULD use a mechanism like that specified in SIP 640 session timer [15]. The UAC MAY send a re-INVITE or an UPDATE 641 message with a new receipt for a payment to prolong the session. 643 There are certain cases where the Merchant may wish to offer a 644 refund. This could occur if the Customer has prepaid for a 10 minute 645 session and the call terminates after 1 minute. In this case, the 646 Merchant may wish to provide a refund for the 9 minutes that were not 647 used. Alternatively, the Customer could provide a receipt to place a 648 call but the destination is busy. In this case, the Merchant would 649 likely want to provide a full refund. 651 The refund mechanism is simple and identical to the Payment Request 652 procedure described in Section 6.1. In this case, the Merchant posts 653 a Payment Request to the Payment Provider specified in the Payment 654 Receipt. 656 If the call ends early or can not be completed, it may still be 657 possible that the Customer has provided a receipt of payment where no 658 service has been delivered. This may have occurred due to an 659 upstream proxy error or a network connectivity problem between the 660 UAC and the UAS. Since the receipt of payment was never delivered to 661 the UAS, there is no immediate mechanism of delivering a refund to 662 the Customer. 664 6.3. Computing costs 666 There are three types of costs: 667 o initial setup costs, 668 o costs per second, and 669 o cost per unit data. 670 All three costs are added together to form the total cost and are 671 assumed to be zero if not specified. The cost of the first time unit 672 block size worth of time and the first data unit block size of data 673 are considered to be included in the initial connection or setup 674 costs. 676 For example, if a call costs 30 cents to connect and then 12 cents 677 per minute and is billed in 15 second increments (rounded down), the 678 cost would be set so that the currency was USD and the currency 679 divisor (power of 10) was 1000 making the initial cost 300, the cost 680 per unit time is 40, and the time unit size is 15000. If the time is 681 to be rounded up, then some extra to cover the price of the first 682 increment would be added to the connect cost. 684 Note that the additional specification of a currency divisor allows 685 all currency amounts to be specified in fixed point. In the above 686 example, a currency divisor of 1000 means that all currency amounts 687 are in tenths of a cent (USD). 689 6.4. Transition Scenarios 691 The deployment of the mechanisms described in this document might 692 take place incrementally. This section provides some information 693 about two likely transition scenarios: Merchant Proxy and Customer 694 Proxy. 696 6.4.1. Merchant Proxy 698 In this scenario, the Customer places a call to a Merchant where the 699 Merchant's UAS does not implement this mechanism. The Merchant's 700 Proxy acts on behalf of the Merchant. The key difference here is 701 that the Merchant's proxy must use SAML URI references instead of 702 SAML assertions and an extra step must be taken by the Proxy to 703 validate the URI reference with the Payment Provider. 705 Note: Many of the normal steps in a SIP call flow have been left out 706 of this example to focus on the pertinent items. 708 Customer Merchant Proxy Payment Provider Merchant 709 | | | | 710 | INVITE F1 | | | 711 |--------------->| | | 712 | 402+Payment Offer F2 | | 713 |<---------------| | | 714 | | | | 715 | Request for Payment F3 | | 716 |-------------------------------->| | 717 | Receipt (Reference) F4 | | 718 |<--------------------------------| | 719 | | | | 720 | INVITE F5 | | | 721 | + Receipt | | | 722 |----------------> | | 723 | 180 F6 | | | 724 |<---------------| | | 725 | | Reference F7 | | 726 | |--------------->| | 727 | | Assertion F8 | | 728 | |<---------------| | 729 | | INVITE F9 | 730 | |-------------------------------->| 731 | | 200 F10 | 732 | 200 F11 |<--------------------------------| 733 |<---------------| | | 735 F1 INVITE: Customer -> Merchant Proxy 737 The Customer sends a SIP INVITE which arrives at the Merchant's 738 Proxy. 740 F2 402 + Payment Offer: Merchant Proxy -> Customer 742 The Merchant's Proxy, acting on behalf of the Merchant, sends a 402 743 response with a Payment Offer back to the Customer. The Payment 744 Offer must indicate that the Payment Provider must provide a URI 745 reference rather than a SAML assertion as a Receipt. 747 F3 Request for Payment: Customer -> Payment Provider 749 Based on the contents of the Payment Offer, the Customer makes a 750 Request for Payment to one of the specified Payment Providers. The 751 Request for Payment specifies that the Payment Provider should return 752 a URI reference. 754 F4 Receipt (Artifact): Payment Provider -> Customer 755 The Payment Provider transfers the appropriate funds to the 756 Merchant's account and returns a URI reference to the Customer. 758 F5 Invite + Receipt: Customer -> Merchant Proxy 760 The Customer inserts a new header containing the URI reference into 761 the INVITE request. 763 F6 180: Merchant Proxy -> Customer 765 The Merchant Proxy immediately sends a 180 response to the Customer 766 indicating that the Receipt is being validated with the Payment 767 Provider. 769 F7 URI Reference: Merchant Proxy -> Payment Provider 771 The Merchant Proxy, acting on behalf of the Merchant, requests the 772 SAML assertion from the Payment Provider by providing the URI 773 reference. 775 F8 Assertion: Payment Provider -> Merchant Proxy 777 The SAML assertion is returned to the Merchant Proxy. 779 F9 INVITE: Merchant Proxy -> Merchant 781 Since the SAML assertion was valid, and was not used before by this 782 Merchant, the Merchant Proxy forwards the INVITE request to the 783 Merchant. 785 6.4.2. Customer Proxy 787 In this example, the Customer endpoint does not implement this 788 payment mechanism so the Customer's Edge Proxy acts on behalf of the 789 Customer. Note that the Merchant's Proxy has been left out of the 790 example. 792 Customer Customer Proxy Payment Provider Merchant 793 | | | | 794 | INVITE F1 | | | 795 |--------------->| | | 796 | 100 F2 | | | 797 |<---------------| INVITE F3 | 798 | |------------------------------------->| 799 | | 402+Payment Offer F4 | 800 | |<-------------------------------------| 801 | | | | 802 | | Request Payment F5 | | 803 | |-------------------->| | 804 | |Receipt(Reference)F6 | | 805 | |<--------------------| | 806 | | | | 807 | | INVITE+Receipt F7 | 808 | |------------------------------------->| 809 | | | 180 F8 | 810 | |<-------------------------------------| 811 | 180 F9 | | | 812 |<---------------| | | 813 | | | Reference F10 | 814 | | |<---------------| 815 | | | Assertion F11 | 816 | | |--------------->| 817 | | | | 818 | | |200 F12 | 819 | |<-------------------------------------| 820 | 200 F13 | | | 821 |<---------------| | | 823 F1 INVITE: Customer -> Customer Proxy 825 The Customer sends an INVITE to the Customer's Edge Proxy (in the 826 same administrative domain as the Customer). 828 F2 100: Customer Proxy -> Customer 830 The Customer's Proxy sends a 100 response to the Customer in order to 831 quench retransmissions. 833 F3 INVITE: Customer Proxy -> Merchant 835 The Customer's Proxy forwards the request to the Merchant. In most 836 cases, the Merchant will also have a Proxy but this has not been 837 indicated in this example. 839 F4 402 + Payment Offer: Merchant -> Customer Proxy 841 The Merchant sends back a 402 response with a Payment Offer to the 842 Customer's Proxy. 844 F5 Request Payment: Customer Proxy -> Payment Provider 846 The Customer Proxy, acting on behalf of the Customer, makes a Request 847 for Payment to the selected Payment Provider specifying that a URI 848 reference is to be returned. It is assumed that the Customer's Proxy 849 would have the payment credentials and Payment Provider preferences 850 for the Customer. 852 F6 Receipt (URI Reference): Payment Provider -> Customer Proxy 854 The Receipt is returned as a URI reference. 856 F7 INVITE + Receipt: Customer Proxy -> Merchant 858 The Customer Proxy now inserts the URI reference as a SIP header in 859 the INVITE request to be sent to the Merchant. 861 F10 Artifact: Merchant -> Payment Provider 863 The Merchant pulls the URI reference from the INVITE and sends a 864 request to the specified Payment Provider to return the SAML 865 assertion. 867 F11 Assertion: Payment Provider -> Merchant 869 When the SAML assertion is verified, the Merchant completes the call 870 and sends a 200 OK response. 872 6.5. Payment Provider Behavior 874 The primary function of the Payment Provider is to receive Requests 875 for Payments over HTTPS, to transfer the currency from one account to 876 another one, and to return a Receipt over HTTPS. 878 A Payment Provider MUST support TLS to offer channel security (with 879 integrity, replay and confidentiality protection). 881 When a Payment Provider receives a Request for Payment, it performs 882 the following steps: 883 1. Verify that the customer-id corresponds to a valid account and 884 that the presented credentials are correct for the given account. 885 If either the account is invalid or the authentication of the 886 account holder was not succesfull then an error message MUST be 887 returned. The procedure for responding with error responses is 888 described in the respective SAML specifications and the Payment 889 Provider MUST respect the SAML specific message processing 890 handling. 891 2. it MUST validate that the currency is acceptable by the Merchant 892 3. it MUST ensure that the Customer has sufficient funds, and 893 4. it MUST verify that the account identifier of the Merchant 894 corresponds to a valid account. 895 5. it MUST create a Receipt as a SAML assertion (or a URI reference) 896 by setting the corresponding fields in the assertion. 897 6. it MUST set the Date to the current time. 898 7. it MUST digitally sign the assertion. 899 8. it MUST transfer the money from the customer's account to the 900 merchant's account. 901 9. it MUST return either the assertion or the Artifact back to the 902 payment requesting entity (depending on the request). 904 6.6. Merchant Fetching Public Key 906 The Merchant needs to be able to fetch the Payment Provider's public 907 key. This MAY be done by an HTTPS request to a URI provided by the 908 Payment Service Provider. The Merchant MAY use some standard online 909 certificate revocation mechanism to protect against the private key 910 being compromised. Note that the Payment Provider may wish to use 911 signing certificates that are only valid for a short period of time. 912 The duration should be determined by the Payment Provider based on 913 the amount of money at risk. 915 7. SIP Extensions 917 7.1. Update response code 402 919 This document updates the 402 response code in RFC 3261 [7] to mean 920 that "A Payment is Required". Other mechanisms are used to indicate 921 what type of payment is required. In this specification, a 922 particular MIME body type indicates the type of payment required. A 923 single 402 may indicate that more than one type of payment is 924 required. Both proxies and UASs can issue a 402 response code. 926 8. Syntax 928 8.1. Payment Offer 930 The Payment Offer contains a list of costs and a list of Payment 931 Providers. The Customer can choose to pay any one of the provided 932 costs and can choose any one of the Payment Providers to use, as long 933 as the Payment Provider supports the currency for the chosen cost. A 934 Merchant can also specify a currency namespace with a particular 935 cost. This allows the Merchant to create non-standard currencies, 936 e.g., airline mileage/points. A cost can also specify an optional 937 minimum and/or maximum cost. 939 The currency is specified as 3 uppercase letters using the ISO 940 currency code from ISO.4217. All cost attributes (initialCost, 941 costPerUnitTime, costPerUnitData, minCost, maxCost) are specified in 942 currency units where the actual cost is to be divided by 943 currencyDivisor. All amounts are base 10 integers with no leading 944 zeros and zero is not a valid entry. The timeUnitSize is in 945 milliseconds. The dataUnitSize is in octets. merchantBits and 946 pspBits are base 64 encoded data 948 Each PaymentServiceProvider provided in a Payment Offer has a 949 serviceUrl attribute which is where the PaymentRequest will be sent 950 to. There is also an optional url attribute which is a general HTTP 951 URL that can provide information about the specific Payment Provider. 953 A simple example is provided with a single charge for a single 954 Payment Provider where the initial cost is $0.25 and the charge is 955 0.06/minute charged in 6 second increments. 957 961 962 964 965 968 971 972 973 975 976 979 980 983 984 985 987 989 Figure 11: Payment Offer Example 991 The XML schema of the PaymentOffer corresponding to the instance 992 document shown in Figure 11 can be found in Section 10.1. 994 8.2. Request for Payment 996 In order to make the generation of the Request for Payment as simple 997 as possible for both the Customer and the Payment Provider, the 998 RequestForPayment is constructed as a SAML Request. The Request for 999 Payment consists of four components: 1001 o The OfferData is copied from the Payment Offer from the Merchant. 1002 o The PaymentServiceProviderData is selected from the possible 1003 Payment Providers by the Customer. 1005 o The amount that needs to be payed. 1006 o Additionally, the Customer might provide authentication 1007 credentials as part of the SAML request. 1009 Note that it is up to the Customer to select a currency. 1011 The OfferData consists of the following fields from the Payment 1012 Request: offerExpiry and merchantBits. 1014 The PaymentServiceProviderData is copied from the chosen Payment 1015 Provider/Cost in the Payment Request consisting of the following 1016 fields: merchantId, serviceUrl, pspBits, currencyNamespace, 1017 currencyDivisor, and currency. 1019 The CustomerData is provided by the Customer and consists of the 1020 following fields: customerId, customerAuth, customerBillingCode and 1021 an amount. The customerBillingCode is optional and could be stored 1022 by the PaymentServiceProvider and included in the transaction history 1023 for the convenience of the Customer. The amount divided by 1024 currencyDivisor indicates the amount of funds being requested to be 1025 transferred from the Customer to the Merchant in currency units. The 1026 customerId is a token identifying the Customer's account with the 1027 Payment Provider and the customerAuth is the authentication 1028 credentials. 1030 The SAML Request MUST be TLS protected. Authentication of the client 1031 MUST be provided, either as part of the TLS handshake or using SAML 1032 specific mechanisms. 1034 The XML schema of the Payment Request is shown in Section 10. 1036 Below is an example 'Payment Request' based on the previous 'Offer' 1037 example with a payment of $0.30. 1039 The following XML instance document shows a AuthnRequest that was 1040 extended to carry the parameters for a payment request. 1042 1043 1057 1058 1059 2005-02-01T13:40:26.52Z 1060 MDE1Mw== 1061 15 1062 1063 https://psp.example.com/paymentService 1064 1065 1000 1066 USD 1067 joe 1068 300 1069 1070 1072 1073 1075 joe@example.com 1076 1078 1080 Figure 12: Request for Payment Example 1082 The XML schema of the PaymentRequest corresponding to the instance 1083 document shown in Figure 12 can be found in Section 10.2. 1085 8.3. Payment Receipt 1087 A SAML assertion or a reference to a SAML assertion is returned, as a 1088 Receipt, in response to the Request for Payment. The SAML assertion 1089 or the URI reference to a SAML assertion is included in the SIP 1090 message in the reINVITE from the UAC. 1092 The following example receipt is returned from the Payment Provider 1093 and corresponds to a Receipt for a payment of $0.30. 1095 1096 1106 1107 1108 Success 1109 1110 1111 1112 1117 www.payment-provider.com 1118 1119 1121 joe@example.com 1122 1123 1126 1129 1130 1131 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 1132 1133 1134 1135 1136 1140 1149 1150 1151 1152 1154 Figure 13: Payment Receipt Example 1156 The XML schema of the PaymentReceipt corresponding to the instance 1157 document shown in Figure 13 can be found in Section 10.3. 1159 8.4. Refunds 1161 Refunds share the same syntax as a Request for Payment. The refund 1162 fields populated from the Receipt are: offerId, offerExpiry, 1163 merchantBits, merchantId, serviceUrl, pspBits, currencyNamespace, 1164 currencyDivisor, and currency. The customerId and customerAuth refer 1165 to the Merchant's account information referenced by the serviceUrl. 1166 The amount to refund is determined by the Merchant at the time of the 1167 refund. 1169 Editor's Note: Add an example here. 1171 8.5. Verifying the Receipt 1173 The Merchant MUST verify the signature in the Receipt by applying the 1174 following steps: 1175 1. Check ReceiptData.Date. If too old, reject. 1176 2. Check whether receipt-id has been accepted in a previous payment 1177 since the TTL used by the UAS. If so, reject. 1178 3. Check whether Offer comes from this UAS. If not, reject. 1179 4. Perform RSA signature verification. UAS chooses the public key 1180 based on PaymentServiceProvider-id. 1182 9. Usage Scenarios for SIP Payment 1184 This section shows the applicability of SIP payment for two example 1185 scenarios. 1187 9.1. SPAM 1189 Payment at risk has been suggested as part of a possible solution to 1190 SPAM in VoIP systems [16]. The idea is that A would call B. If A was 1191 not on B's white list, B could ask A to pay 5 cents for the privilege 1192 of ringing B's phone. A could pay, and if B wished, B could refund 1193 the 5 cents by simply doing a second payment from B to A. The payment 1194 service provider would collect two transaction fees in this scenario. 1196 Another possible scenario is that B simply requests that A donate 5 1197 cents to one of B's favorite charities and show B the receipt for 1198 this transaction. 1200 9.2. Micro Billing 1202 In this scenario, a merchant running a PSTN GW may charge a customer 1203 5 cents to connect and operate for the first 90 seconds and then may 1204 charge 5 more cents for each additional minute. The customer would 1205 initially transfer 5 cents and then, before the 90 seconds ran out, 1206 would transfer another 5 cents and keep on doing this until the call 1207 ended. 1209 10. XML Schemas 1211 This section defines the XML schema for the protocol introduced in 1212 this document. 1214 10.1. PaymentOffer XML Schema 1216 This section shows the XML schema for the PaymentOffer that the 1217 Merchant sends to the Customer. 1219 1225 1226 1227 1228 1229 1230 1231 1232 1233 1236 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1253 1257 1261 1265 1269 1273 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1302 1305 1308 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1325 1328 1331 1332 1333 1335 PaymentOffer XML Schema 1337 10.2. Payment Request 1339 This section shows the XML schema for the PaymentRequest that is used 1340 inside the SAML AuthnRequest request message. 1342 1343 1348 1350 1351 1352 1355 1358 1361 1364 1367 1370 1373 1376 1379 1382 1385 1386 1387 1389 Payment Request XML Schema 1391 10.3. Payment Receipt 1393 This section defines the XML schema for the Payment Receipt that is 1394 used in the SAML Response message returned after a successful 1395 processing of the SAML AuthnRequest. 1397 1398 1406 1407 1408 Document identifier: 1409 payment-receipt-schema 1410 Location: 1411 http://www.tschofenig.com/svn/draft-jennings-sipping-pay/Schema/ 1412 Revision history: V1.0 1413 (June, 2006): Custom schema for SIP Payment attribute profile. 1414 1415 1416 1417 1418 1419 1421 1423 1425 1427 1429 1431 1433 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1448 Payment Receipt XML Schema 1450 11. HTTP Binding 1452 This section defines an HTTP [10] binding for the protocol between 1453 the Customer and the Payment Provider, which all conforming 1454 implementations MUST support. 1456 The three request messages are carried in this binding as the body of 1457 an HTTP POST request. The MIME type of both request and response 1458 bodies should be "application/xml", except that a SAML assertion 1459 SHOULD have the MIME type "application/samlassertion+xml". 1461 The Payment Provider SHOULD populate the HTTP headers so that they 1462 are consistent with the contents of the message. In particular, the 1463 "Expires" and cache control headers SHOULD be used to control the 1464 caching of any SAML assertion. The HTTP status code SHOULD have the 1465 same first digit as any "contextResponse" or "error" body included, 1466 and it SHOULD indicate a 2xx series response when a SAML assertion is 1467 included. 1469 This binding also includes a default behaviour, which is triggered by 1470 a GET request, or a POST with no request body. In this case, the 1471 Payment Provider MUST attempt to provide a SAML assertion. 1473 This binding MUST use TLS as described in [8]. TLS provides message 1474 integrity and confidentiality between the Customer and the Payment 1475 Provider. The Payment Provider MUST use server-side authentication. 1476 Client authentication can either be provided as part of the TLS 1477 handshake or using HTTP specific mechanisms. 1479 12. Security Considerations 1481 The security properties of the proposed protocol depends on the 1482 security of the communication between the three parties. The 1483 following threats and countermeasures have been considered: 1485 12.1. Stolen Assertion 1487 Threat: 1489 An adversary can eavesdrop on the communication between the 1490 Customer and the Payment Provider and between the Customer and the 1491 Merchant and thereby learn the SAML assertion (Receipt). The 1492 adversary could use this assertion to request a service from the 1493 Merchant on behalf of the legitimate Customer. 1495 Countermeasures: 1497 Two countermeasures are provided to deal with this treat. The 1498 communication between the Customer and the Payment Provider must 1499 be confidentiality, integrity and replay protected. The 1500 communication between the Customer and the Merchant SHOULD 1501 experience hop-by-hop protection (e.g., TLS in a hop-by-hop 1502 fashion between the Customer, SIP proxies and the Merchant) and 1503 end-to-end security using the SIP Identity mechanism. 1504 Furthermore, the content of the requested SAML assertion contains 1505 statements that prevent reusage of the SAML assertion in other 1506 contexts. The Offer, for example, provides a merchantBits value 1507 that allows the Merchant to match the Offer to the Receipt. The 1508 identities of the Customer and the Merchant are included in the 1509 Receipt and the lifetime might be limited. 1511 12.2. MitM Attack 1513 Threat: 1515 Since the SAML assertion is carried within a SIP message sent by 1516 the Customer towards the Merchant an intermedidate SIP proxy could 1517 use the assertion in order to impersonate the user towards the 1518 Merchant in future protocol sessions. 1520 Countermeasures: 1522 This document does not assume that the assertion is bound to a 1523 symmetric or an asymmetric key although SAML provides this 1524 capability using the holder-of-the-key concept. If there is no 1525 such holder-of-the-key concept utlized with the assertion then 1526 only the content of the assertion can be used to prevent replay 1527 attacks and man-in-the-middle attacks. Similarly to the threat 1528 described in Section 12.1 the content of the assertion limits its 1529 usage to particular endpoints, potentially for a particular 1530 duration, for a particular service and for certain amount of time. 1532 12.3. Forged Assertion 1534 Threat: 1536 A malicious Customer or a malicious intermediate SIP proxy could 1537 forge or alter a SAML assertion in order to communicate with the 1538 Merchant to lead to unexpected behavior or even to refunding to a 1539 preselected account. 1541 Countermeasures: 1543 To avoid this kind of attack, the Payment Provider must assure 1544 that proper mechanisms for protecting the SAML assertion is 1545 provided. It is RECOMMENDED to protect the assertion using a 1546 digital signature. 1548 12.4. Replay Attack 1550 Threat: 1552 An adversary might eavesdrop an assertion in order to later replay 1553 it to gain access to resources (e.g., to access a SIP service). 1555 Countermeasures: 1557 When the Customer transmits a SIP message that requires payment 1558 then the Merchant creates an Offer that contains a merchantBits 1559 value. The Offer will be used by the Customer to obtain an 1560 assertion by the Payment Provider and will again be presented to 1561 the Merchant. The Merchant is therefore able to determine whether 1562 the merchantBits is still valid and that it can be associated with 1563 an Offer. The Offer is only valid for a certain time. Timestamp 1564 information carried inside the assertion might also indicate a 1565 validity timeframe. 1567 13. IANA Considerations 1569 13.1. Payment-Receipt Header 1571 Add the following entry to the header sub-registry. 1573 Header Name compact Reference 1574 ----------------- ------- --------- 1575 Payment-Receipt [RFCXXXX] 1577 13.2. 402 Response 1579 Add the following entry to the response code sub-registry under the 1580 "Request Failure 4xx" heading. 1582 402 Payment Required [RFCXXXX] 1584 13.3. charge+xml 1586 To: ietf-types@iana.org 1587 Subject: Registration of MIME media type application/charge+xml 1589 MIME media type name: application 1591 MIME subtype name: charge+xml 1593 Required parameters: None 1595 Optional parameters: charset 1596 Same as charset parameter of application/xml [RFC3023] 1598 Encoding considerations: 1599 Same as for application/xml [RFC3023] 1601 Security considerations: TBD 1603 Interoperability considerations: TBD 1605 Published specification: None 1607 Applications which use this media type: Any MIME-compliant transport 1609 Additional information: 1610 Magic number(s): None 1611 File extension(s): None 1612 Macintosh File Type Code(s): None 1614 Person & email address to contact for further information: 1615 Hannes Tschofenig Hannes.Tschofenig@siemens.com; 1617 Intended usage: COMMON 1619 Author/Change controller: 1620 the IESG 1622 13.4. IANA Registration for the SIP SAML Header 1624 The SAML header is created by this document, with its definition and 1625 rules in Section 5 of this document. 1627 13.5. IANA Registration for Two New SIP Option Tags 1629 Two new SIP option tags are created by this document, "SAML" and 1630 "Unknown-SAML", with the definitions and rules for each in Section 5 1631 of this document. 1633 13.6. IANA Registration for Response Code 4XX 1635 Reference: RFC-XXXX (i.e., this document) 1636 Response code: 424 1637 Default reason phrase: Bad SAML Information 1639 The 'application/samlassertion+xml' URN sub-namespace and Content- 1640 type is already registered by IANA (see [11]). 1642 14. Acknowledgments 1644 The authors would like to thank James Polk and Brian Rosen for their 1645 work with SIP Location Conveyance. Text from their draft was reused 1646 in this document due to the perceived similarity of the mechanisms. 1648 15. References 1650 15.1. Normative References 1652 [1] Tschofenig, H., "SIP SAML Profile and Binding", 1653 draft-ietf-sip-saml-02 (work in progress), May 2007. 1655 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1656 Levels", BCP 14, RFC 2119, March 1997. 1658 [3] Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", OASIS 1659 SSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01, 1660 April 2005. 1662 [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1663 Identity Management in the Session Initiation Protocol (SIP)", 1664 RFC 4474, August 2006. 1666 [5] Jennings, C., "Certificate Management Service for The Session 1667 Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in 1668 progress), March 2007. 1670 [6] Levinson, E., "Content-ID and Message-ID Uniform Resource 1671 Locators", RFC 2392, August 1998. 1673 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1674 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1675 Session Initiation Protocol", RFC 3261, June 2002. 1677 [8] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1679 [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1680 RFC 2246, January 1999. 1682 [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1683 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1684 HTTP/1.1", RFC 2616, June 1999. 1686 [11] OASIS Security Services Technical Committee (SSTC), 1687 "application/samlassertion+xml MIME Media Type Registration", 1688 IANA MIME Media Types Registry application/samlassertion+xml, 1689 December 2004. 1691 [12] International Organization for Standardization, "Codes for the 1692 representation of currencies and funds", ISO Standard 4217, 1693 2001. 1695 15.2. Informational References 1697 [13] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1698 1.0", RFC 2801, April 2000. 1700 [14] Mills, D., "Network Time Protocol (Version 3) Specification, 1701 Implementation", RFC 1305, March 1992. 1703 [15] Donovan, S. and J. Rosenberg, "Session Timers in the Session 1704 Initiation Protocol (SIP)", RFC 4028, April 2005. 1706 [16] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol 1707 (SIP) and Spam", draft-ietf-sipping-spam-04 (work in progress), 1708 February 2007. 1710 [17] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: 1711 Timestamps", RFC 3339, July 2002. 1713 Authors' Addresses 1715 Cullen Jennings 1716 Cisco Systems 1717 170 West Tasman Drive 1718 MS: SJC-21/2 1719 San Jose, CA 95134 1720 USA 1722 Phone: +1 408 902-3341 1723 Email: fluffy@cisco.com 1725 Jason Fischl 1726 CounterPath Solutions, Inc. 1727 Suite 300, One Bentall Centre, 505 Burrard Street 1728 Vancouver, BC V7X 1M3 1729 Canada 1731 Phone: +1 604 320-3340 1732 Email: jason@counterpath.com 1734 Hannes Tschofenig 1735 Siemens Networks GmbH & Co KG 1736 Otto-Hahn-Ring 6 1737 Munich, Bavaria 81739 1738 Germany 1740 Email: Hannes.Tschofenig@siemens.com 1741 URI: http://www.tschofenig.com 1743 Gyuchang Jun 1744 Bitpass, Inc. 1745 3300 Hillview Avenue, Suite 165 1746 Palo Alto, CA 94304 1747 USA 1749 Phone: 650 354-1882 1751 Full Copyright Statement 1753 Copyright (C) The IETF Trust (2007). 1755 This document is subject to the rights, licenses and restrictions 1756 contained in BCP 78, and except as set forth therein, the authors 1757 retain all their rights. 1759 This document and the information contained herein are provided on an 1760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1762 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1763 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1764 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1767 Intellectual Property 1769 The IETF takes no position regarding the validity or scope of any 1770 Intellectual Property Rights or other rights that might be claimed to 1771 pertain to the implementation or use of the technology described in 1772 this document or the extent to which any license under such rights 1773 might or might not be available; nor does it represent that it has 1774 made any independent effort to identify any such rights. Information 1775 on the procedures with respect to rights in RFC documents can be 1776 found in BCP 78 and BCP 79. 1778 Copies of IPR disclosures made to the IETF Secretariat and any 1779 assurances of licenses to be made available, or the result of an 1780 attempt made to obtain a general license or permission for the use of 1781 such proprietary rights by implementers or users of this 1782 specification can be obtained from the IETF on-line IPR repository at 1783 http://www.ietf.org/ipr. 1785 The IETF invites any interested party to bring to its attention any 1786 copyrights, patents or patent applications, or other proprietary 1787 rights that may cover technology that may be required to implement 1788 this standard. Please address the information to the IETF at 1789 ietf-ipr@ietf.org. 1791 Acknowledgment 1793 Funding for the RFC Editor function is provided by the IETF 1794 Administrative Support Activity (IASA).