GSoC2013 Open Source PaySwarm API in Python

The Open Web Payments in PaySwarm initiative, is a payment specifications that could be used by anyone to collect money for prespecified assets, such as online merchant websites, teams collaborations, micropayments through different channels .. etc. A PaySwam API is the piece of software that allows using PaySwarm infrastructure from different clients which allows vendors to embed the required specifications in their channels. This project is a Python implementation of such an API, that allows easy implementation of different scenarios in Python web apps.

Personal Details

Name: Amr Fahmy Email: A.Fahmy[at]cloud-11[dot]com Personal Website: http://www.amrfahmy.info Skype ID or SIP address: amr.karam.fahmy IRC: Amr-Fahmy Phone number: +202 01009829173 School Name: Helwan University Faculty of Computer and information system Years completed: 4 years Programming Languages: JavaScript (Intermediate), Python (Intermediate), REST APIs(Intermediate), WebKeys(Beginner), PaySwarm(Beginner), PHP (Advanced), Joomla(Advanced), Google Apps Script(Advanced), C/C++(Advanced), C#(Advanced).

PaySwarm Web Payments Overview

PaySwarm gives you the mechanism and the protocol to mark items up for sell and put them on the website so that any user using user agent that implements PaySwarm protocol can buy them without the need to register an account at the vendor website or provide additional data to purchase the payment process. It decentralizes listing things for payments process and selling process from the payment processing. So the PaySwarm lets you use payment service without restricting interactions between you and the vendor if you need to buy anything.

The goal is also not just creating the traditional concept that the user click one click and everything should be done without knowing the how it is working, we want to use extensible Open Source so every developer who is interested in this specifications can add more features to this tool. This will increase the usage of Web Payments over the internet.

PaySwarm API

These days there are many number of popular authorization mechanisms that provide dynamic access to control the resources, large number of them did not address message materialization and message security. Now the most important reason for public and private key is a strategy to achieve the materialization of the message via digital signature and secure messaging via encryption, also the private and public key help the access control to resources.

One of the hardest things that we will face is developing an extensible, decentralized Public Key Infrastructure for the web. Linked Data principles help in developing decentralized Public Key Infrastructure on the web.

So the previous points will help us to achieve the future of the messaging in web service that depends on :

Message materialization (signing). Message security (encryption). Dynamic access control to resources.

Web Keys should not be confused with TLS, actually Web Keys can be operating in any environment regardless there is TLS or not.

PaySwarm API Main Components

1. Identity (Key Registration) The following is key registration algorithm that should be followed by a key agent utilizing the PaySwarm Python API as currently specified in Web Keys 1.0 draft: The user agent (browser) request from the key agent (Python app) to generate public and private key. The key agent (Python app) retrieves the key listing service from the configuration service IRI as following: Base IRI for the key listing service (obtained for example from client e.g: dev.payswarm.com) + suffix (/.well-known/web-keys) An HTTPS GET request is performed on the configuration service IRI (dev.payswarm.com/.well-known/web-keys) The result will be a JSON-LD document using the context specified at https://w3id.org/web-keys/v1 containing a flat set of key-value pairs, for now this key is mandatory ‘publicKeyService’. The key agent (Python app) responds to the user agent with the HTTP 302 to the key listing service URL. The key listing service in turn associates the key agent (Python app) with the key listing account based on the provided public key. UI will ask user to login if there is no active login session. The key listing service specifies a number of the key agent (Python app) configuration values and encrypts the JSON-LD reponse message using the Public Key provided. The response will be as following: It must contains 'publicKey' configuration The JSON-LD response is compacted and encrypted using Public Key associated with the registration request. Response is sent to 'registration-callback' IRI via POST request initiated by user agent. The key agent (Python app) then decrypts the base64-encoded stream then extracts and stores the location of 'publicKey' for later use.

Python API

PythAPI.Client() Client class definition PythAPI.GenerateKeyPairs() Generate pub/prv key pairs for use in registration PythAPI.AddTrustedAuth() Set the payment authority configuration service IRI PythAPI.GetRegUrl() Get the key listing service URL from the configuration service IRI PythAPI.EncryptMessage() using authority public key PythAPI.DecryptMessage() using key agent private key PythAPI.ParseAuthResponse() Decrypt the response from Payment Authority and get key-value pairs

2. Assets and Listings registration Asset is a description of a product or service. It typically describes something to be sold, who created it, a set of restrictions on selling it, and a validity period. On the other hand Listing is a description of the specific terms under which an asset is offered for sale.

Python API

PythAPI.Asset() Python Asset class for bootstrapping Asset definition. PythAPI.Listing() Python Listing class for bootstrapping Listing definition and will contains an Asset hash. PythAPI.Sign() Digitally sign an Asset/Listing specs using key agent public and private keys. PythAPI.Hash() Generate a Cryptographic hash for an Asset/Listing to be used when it's referenced by the listing. PythAPI.Publish() Upload a JSON-LD document that contains an Asset and its associated Listing to a PaySwarm listing service URL.

Suggested Python methods that will be used in this process:

3. Purchasing Three main items involved in purchasing process: Purchase Request: A purchase request is sent to a PaySwarm Authority when a purchase is requested by the customer. It contains details about the asset and listing that the buyer would like to purchase. Contract: A contract is an electronic document that expresses an agreement between all parties involved in a transaction. It contains the asset, digitally signed by the asset provider, and the listing, digitally signed by the vendor. Receipt: A receipt is the result of a successful purchase. Its main use is to prove that the sale of an asset to a particular customer was completed successfully.

Python API

PythAPI.RetrieveListing() from a PaySwarm listing service URL. PythAPI.PurchaseRequest() Make a Pruchase Request using: the retrieved listing, customer's identity, customer's source financial account, and digitally signed using customer's pub/prv keys. PythAPI.PurchaseAndGetReceipt() Sends the Purchase Request and if successful, retrieve a digitally signed receipt. The receipt will contain the transaction ID for the sale, which can then be used to retrieve the full contract for the sale PythAPI.GetContract() Using Receipt's TransactinID

P.S: These APIs are subject to change during implementation milestones.

What have you done so far with this idea

First, I have did a lot of research in this field, get used to the JSON-LD concept, although I have did some experiments on Private and Public key cryptography.

Also, I’ve started to build a prototype of the project:

Source on GitHub https://github.com/Amr-Fahmy/payswarm-python Hosted app on Google App Engine http://payswarm.appspot.com/

Anticipated challenges

This field has a lot of challenge as I must have a lot of experience in Web Keys and its importance as new payment method for the user. This involves: Increase innovation. Improve service quality. Reduce costs. Enhance capabilities in key competitive areas. Potential mentors I had a lot of great discussions going with Manu Sporny msporny@digitalbazaar.com, and I see him actually an amazing mentor in this field and he has great experience in Web Payments and he is providing me with some helpful links and feedbacks.

Schedule of Deliverables

May 6th - Jun 17th I will revise the plan with the mentor, and start do more research to improve my understanding of how Payswarm is working. Also I will set up development environment and will experiment with Payswarm.js code. Jun 17th - Jul 1st Start coding the Web Keys Client library in Python. At this period I’d be focusing on Web Keys Registration API. Jul 1st - Jul 15th Start coding the Assets and Listings registration API Jul 15th - Aug 2nd Testing and bug fixing the developed API (Web Keys Registration and Assets/Listings registration API) and developing usage samples Aug 2nd Submit Mid-term Evaluation Aug 2nd - Aug 16th Start coding in Purchasing process API. Aug 16th - Aug 31st Build more usage examples including an UI example using Python as backend and based on Django framework Aug 31st - Sep 16th Testing and bug fixing the developed API (Purchasing API) Sep 16th - Sep 23rd Write the documentation of the API. Also, time for code review with community and more bug fixing. Sep 23rd - Sep 27th Submit Final Evaluation

After final evaluations Translation, asking community for feedback, testing, and make sure all things are just working fine. I will keep developing Web Keys Client and will be ready to move to some other tasks. Other commitments I will have exams which will begin at May 20th and ends at June 15th. During this times I will work on the project for 15 - 20 hours per week.

Minimum time involvement estimation:

May 10th - May 20th 35 - 40 hours per week May 20th - Jun 15th 15 - 20 hours per week (My Exams period) Jun 4th - Jun 25th 35 - 40 hours per week Jun 26th - Aug 15th 45 - 50 hours per week

Work Experience

Google Apps Customer Solution Engineer, December 2012 - Present (5 months): Google Apps Customer Engineer , I’m responsible for deploying, configuring and migrating to Google Apps for Business and for Education while providing training workshops when needed , Cloud11 is a Company responsible for holding large systems in Cloud systems. School Major Manager, March 2010 - Present (3 years 2 months): Good Idea Group is a company responsible for Italian brand vacuum product which help in healthy & clean life.I was responsible for handling IT issues for than 29 users i was also responsible for handling system automated flow for the employees to get everything automated in our company. Google Student Ambassador at Google, July 2011 - July 2012 (1 year 1 month): The Google Student Ambassador Program is an opportunity for students to act as liaisons between Google and their universities

Academic Experience

Academic Institution: Helwan University (Helwan, Egypt). Current Program: My major is Computer Science, my degree type I'm working on is B.Sc., I'm in the fourth year. Anticipated Graduation: 2013/2014 Academic Performance: Software Development (B+) Google Apps Script (A+) Joomla open platform (B+) Programming (Object oriented object) (B+) C++ (B+) ASP.NET (A+) PHP (B+) JSP (B+) MySQL (B+) Security & Cryptography (B+) References Dr.Ayman Atya : <ayman@fcih.net> Dr Mottaz Abdelfattah: <mottazabdelfattah@gmail.com> Ahmed Farrag: <a.m.farrag@gmail.com>