Difference between revisions of "GSoC2013 Web Payments WebKeys Client"
(→Open Source Development Experience)
|Line 232:||Line 232:|
==Open Source Development Experience==
==Open Source Development Experience==
'''Coding Experience''': ''
'''Coding Experience''': ''
experience have with for a . ''
Revision as of 21:03, 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.
Name: Amr Fahmy
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
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
2 The Key Registration Process
2.1 Key Registration Terms:
- 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
how a key listing service must make the key IRI returned to the registrant a machine-readable document
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].
- 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 email@example.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
|April 30 - May 20||I will start to make best resources, researches and to configure my machine OS to start experimental many of the opensource code to improve my self to understand more how it really work.|
|28 May – 3 June||Finishing the models, bug fixing.|
|4 June – 10 June|
|11 June – 17 June|
|18 June – 24 June|
|25 June – 1 July|
|2 July – 8 July|
|9 July -12 July|
|16 July – 22 July|
|23 July – 29 July|
|30 July – 5 August|
|6 August – 12 August|
|13 August – 23 August|
|August 24||Final evaluation deadline.|
|After final evaluations||Translation, asking community for feedback, testing, and make sure all things just working fine. I will keep developing for Webkey client and will move to some other tasks|
Open Source Development Experience
Coding Experience: I'am a Google Apps Deployment specialist and I have a good experience in Google Open source API's, I have worked with Google App engine for Platform as a services which we deploy application on Google app engine with Google script.
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 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.
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.