Service Initiation in the E-Payment Environment

Harviatama Librianto Sophian 2301930974

Use of services may include some sort of remuneration, and this is also true for many communication systems where an entity receiving a call should be allowed to charge the caller for his or her participation. In order to allow for fair communication between two communicating parties, this is a required step, and it is also an important approach for minimizing the viability of SPAM. This draft provides a method for doing this in SIP via the use of the Security Assertion Markup Language (SAML) (SAML). In order to function as a payment provider, it is necessary to rely on a third party. It is intended for low-value transactions. Unlike other authentication, authorization, and accounting (AAA) backend infrastructures, it is not intended to offer the same level of functionality. The traditional e-banking system will be completely transformed by this new payment mechanism. Users are no longer led to an e-payment interface when making an online payment, such as a credit card payment gateway and/or an acquiring bank login page.

Instead, payment initiation services are used to prevent the log-in from being completed directly. Payment Initiation Service Providers (PISPs) are trustworthy holders of login and transfer credentials that have been approved on the user’s behalf, and they may execute direct payments as a result of their direct banking interface with the financial institution.

As the name implies, payment initiation service providers (PISPs) are businesses that offer payment initiation services, such as Unnax’s Payments API. The complete new payment distribution technique that PISPs offer is made feasible by banks granting access to their client data via specialized open APIs (application programming interfaces). This has just been enforced by the European Union under PSD2, the regulatory framework that underpins Open Banking services.

References

1. Tschofenig, H., “SIP SAML Profile and Binding”, draft-IETF-sip-saml-00 (work in progress), June 2006.
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. Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
5. Dierks, T. and C. Allen, “The TLS Protocol Version 1.0”, RFC 2246, January 1999.
6. 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.
7. 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.
8. OASIS Security Services Technical Committee (SSTC), “application/samlassertion+xml MIME Media Type Registration”, IANA MIME Media Types Registry application/samlassertion+xml, December 2004.
9. Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP)”, draft-ietf-sip-certs-00 (work in progress), May 2006.
10. Mishra, P., Philpott, R., and E. Maler, “Conformance requirements for the Security Assertion Markup Language (SAML) V2.0”, OASIS Standard saml-conformance-2.0-os, March 2005.