Difference between revisions of "GSoC2013 Web Payments WebKeys Client"

From W3C Wiki
Jump to: navigation, search
(Personal Details)
(Personal Details)
Line 81: Line 81:
Check this image
Check this image
[http://commons.wikimedia.org/wiki/File:WebkeyGsoc2013.png Webkey-Registeration-Gsoc2013]
[http://commons.wikimedia.org/wiki/File:WebkeyGsoc2013.png Webkey-Registeration-Gsoc2013]
3. Discovery
3. Discovery

Revision as of 20:24, 27 April 2013

GSoC2013 Web Payments WebKeys Client

the Web Payments work, will have a huge impact on the way that we deal with money as a society on the Web. It has very far-reaching implications and will lay the groundwork for a fully programmable financial network that will be accessible to everyone on the Web. The goal of the work is the democratization of finance; it will place the financial tools that have typically only been available to large banks and corporations into the hands of everyday people.

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

Phone number: +202 01009829173

School Name: Helwan University.

Years completed: 4 years

Programming Languages: PHP (Advanced),Joomla(Advanced), Google Apps Script(Advanced), C(Advanced), C#(Advanced), JavaScript (Intermediate), Python (Intermediate), REST APIs(Beginner), Web Keys(Beginner), PaySwarm(Beginner).

Link to project description: http://www.w3.org/wiki/GSoC2013_Web_Payments_WebKeys_Client

Describe your idea in detail:The Web Payments work, if successful, will have a huge impact on the way that we deal with money as a society on the Web, The Web Payments work is built on top of the previous two technologies, RDFa and JSON-LD. Manu Sporny: "The Web has fundamentally transformed the way we publish and interact with information. However, the way we reward people for creating that content has not changed. The Web’s foundation was not built to transmit and receive funds with the same ease as sending and receiving an email"

So Why Webkey Services?

Webkey eServices is dedicated to using advanced outsourcing capabilities and services to help users become high-performance businesses that consistently exceed their peers by quantifiable standards, outperforming them across economic cycles as well as new generations of leadership. Outsourcing with us can drive high performance through:

  • Increased efficiencies and leading practices.
  • Improved operational excellence.
  • Performance improvements.
  • Better access and utilization of technology.

The Web Payment Requirements:

  • It must be decentralized.
  • It must be an open, patent and royalty-free standard.
  • It must be designed to work with Web architecture like URLs, HTTP, and other Web standards.
  • It must allow anyone to implement the standard and interoperate with others that implement the standard.

The above requirement Which Manu Sporny has described before that there is another requirement that it will be good feature for web payment:

  • It must enable choice among customers, vendors, and payment processors, in order to drive healthy market competition.
  • It must be extensible in a decentralized way, allowing application-specific extensions to the core protocol without coordination.
  • It must be flexible enough to perform payments as well as support higher order economic behaviors like crowdfunding and executing legal contracts.
  • It must be secure, using the latest security best practices to protect the entire system from attack.
  • It must be currency agnostic, supporting not only the US Dollar, the Euro, and the Japanese Yen, but also supporting virtual currencies like Bitcoin and Ven.
  • It must be easy to develop for and integrate into the Web.

So from my point of view the future web-service will be depend on:

  • Message verifiability
  • Secure messaging
  • Dynamic access control to resources

The challenge has always been in building an extensible, distributed, Public Key Infrastructure for the Web. This specification details how a decentralized Public Key Infrastructure can be built on top of the Web using Linked Data principles. This system can then be used to easily achieve message verifiability, secure messaging, and dynamic access control to resources on the Web.

Manu Sporny said: Web Keys are not a replacement for Transport Layer Security, but are designed to work in concert with the security protocol. Web Keys are also capable of in environments where TLS is not available to the application.

1 Key Technologies

Technologies utilized in this specification include the JavaScript Object Notation for Linking Data [JSON-LD], the HyperText Transfer Protocol [HTTP11], and the Advanced Encryption Standard [AES].

2 The Key Registration Process

2.1 Key Registration Terms:

  • actor
  • account
  • user agent
  • key agent
  • key listing service
  • configuration service
  • public key registration service

2.2 Key Owner Registration 2.3 Web Key Registration 2.4 Security Concerns for Registration

Check this image Webkey-Registeration-Gsoc2013

3. Discovery

how a key listing service must make the key IRI returned to the registrant a machine-readable document

4. Messaging

4.1 Messaging Terms

The following terminology is used to describe concepts used to generate and secure messages that are sent and received using Web Keys. Many of these terms are borrowed from public/private key cryptography. A more complete description of public/private cryptography can be found in The Advanced Encryption Standard [AES].

  • message
  • public key
  • private key
  • signed message
  • intermediate value
  • encrypted message

4.2 Message Signature Algorithm

This algorithm ensures that the originator of an Web service call can be verified as long as the public key can be retrieved by the receiver. A message is provided as input and, using a private key and a public key IRI, a signed message is produced as output.

4.3 Message Signature Verification Algorithm

In order to ensure a secure communication environment the following algorithm should be used to verify all request signatures in the system. A signed message is provided as input and an indication of whether the signature is valid or a forgery is produced as output.

4.4 Message Encryption Algorithm

This algorithm ensures that a message intended for a particular recipient can be obfuscated such that only the intended recipient can read the message. A message is provided as input and, using a public key and a public key IRI, a encrypted message is produced as output.

4.5 Message Decryption Algorithm

This algorithm is used to decrypt an encrypted response. The input is an encrypted message and the result is the original unencrypted message.

4.6 Security Considerations

Since this specification describes a financial system, the security of the communication in the system is of utmost importance. The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software.

4.6.1 The Response Nonce

The nonce mechanism is used in order to prevent replay attacks, but implementers must be aware that it is not capable of preventing man-in-the-middle attacks. Only a full end-to-end encryption channel is capable of accomplishing that feat and if implementers are concerned about man-in-the-middle attacks, they are strongly advised to run all callbacks over HTTPS.

5. Permission and Access Rights Delegation

During the Key Registration Process, a key listing service may ask the actor that is registering to grant a number of permissions and access rights to any agent that digitally signs a message to a Web service using the registered key. Note that this mechanism is similar to the OAuth permission granting mechanism and can be used in place of OAuth if the system requires both Permission and Access Rights Delegation as well as digital signatures. To take advantage of this mechanism, a agent would digitally sign a message requesting that a certain action be performed on behalf of the actor.

6. Key Revocation and Expiration

In order for a key pair to be revoked, the revocation-Date must be associated with the key. In order to specify an expiration date for a key pair, the expiration-Date must be associated with the key. All software systems utilizing the key pair must honor the revocation and expiration dates and fail to verify any signatures made on or after the date and time specified. Similarly, the created date establishes the date and time on which the key can be used to digitally sign and encrypt data. All software systems utilizing the key pair must honor the creation date and fail to verify any signatures made before the date and time specified.

What have you done so far with this idea: What I have did is some research in this field, tried the JSON-LD concept theoretical and I though it is very interest to continue this field and to improve it, However I have did so far some expermintals on the webkeys private and public key on my freebsd machine.

Anticipated challenges: This field has a lot of challenge as you must have a lot of experience in the web-key as it is very important internet service for the user to for example transfer there money like:

  • To increase innovation.
  • Improve service quality.
  • Reduce costs.
  • Enhance capabilities in key competitive areas.

Potential mentors: I had a small discussion with Manu Sporny msporny@digitalbazaar.com actually he is amazing mentor in this field he has alot of experience in the webpayment service and he provide me with some helpful links.

Schedule of Deliverables

Milestones and deliverables schedule: What are the milestones and deliverables for your project? It should take the form of a list with dates and deliverables. A task and/or milestone for each week of the development period is a good idea, since it will help your mentor keep you on track to complete your project. For example:

  • Month/Date - Revise project plan with mentor, set up development environment
  • Month/Date - Determine how to structure plugin, begin coding
  • Month/Date - Submit first draft code for review

etc. You get the idea. The more detailed you are, the more convinced we'll be that you've thought about this project realistically. If accepted, the first thing you'll do will be to work with your mentor to define a very specific commitment regarding deliverables and schedule to determine eligibility for full student payment at the halfway mark and at the end of the program. This will help limit disappointment for both mentors and students.

Other commitments: Do you have any other commitments during this time that could impact your ability to be online, coding and/or communicating with your mentor? Include school, work and family commitments.

Open Source Development Experience

Coding Experience: Explain all relevant prior experience that you have had with programming for an open source project. Languages, toolkits, IDEs, how do you work best (group or individual-based work, etc.). This may be other closed source projects, but giving a link to previous open source work that you've done would be ideal.

Work Experience

Work Experience: List any work experience you've had relevant to the proposed project, blogging, or software development. If you've bagged groceries, it's probably not relevant, but it shows that you can work in a collaborative environment, so a full resume isn't a bad idea! You can include paid jobs, internships, academic assistantships, etc. Identify for each job what your responsibilities were and how your success was measured (deadlines/deliverables, or just being there?).

Academic Experience

Academic Institution: Identify your college/university by name, and give its location (city, state/province/etc, country).

Current Program: Identify your major, what degree type you are working on (BA, MS, PhD, etc), and what year you are (freshman, junior, 2nd year candidate, etc).

Anticipated Graduation: Give the year you expect to complete your program.

Academic Performance: List what you're studying in university/college that is relevant, how you're doing in your program, etc. Please be specific about which programming courses you've completed. An official transcript is not necessary, but cutting and pasting the course names and grades you've earned so far will help us understand your background better and tailor project scope accordingly.

GSoC for Credit: Are you planning to use your GSoC project as an independent study for college credit? For this question, write "Yes" or "No". If yes, please include the title of your independent study and the name and email address of the professor who would be your independent study advisor.

References: Please give the names and email addresses of up to 4 computer science professors (and/or relevant employers) who can vouch for your experience.

Why W3C

You're applying to work with the World Wide Web Consortium (W3C) during GSoC because: Tell us why you chose to apply with us. Be as specific as possible.

After GSoC, you envision your involvement with W3C will be: Over? Ongoing? Evolve into being a core participant or committer? Tell us what you envision your participation with the W3C will be like after GSoC2013 comes to an end?

Helpful Links for Students


This template is based heavily on the WordPress GSoC template, much thanks to the WP Community for putting that together.