- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 19 Nov 2014 09:48:39 -0500
- To: Web Payments <public-webpayments@w3.org>
On 11/19/2014 05:10 AM, Melvin Carvalho wrote: > 1. How do I know where to POST this file to, given that I may know > the authority already? At the moment, discovery happens by hitting a well-known URL. It's the same basic process as outlined in the Secure Messaging spec: https://web-payments.org/specs/source/secure-messaging/#the-key-registration-process The key things to look out for are the "configuration service", and the use of .well-known URLs. So, I believe our current implementation does something like this: 1. Hit the domain of the payment processor that's going to do the transaction, for example: https://dev.payswarm.com/.well-known/payswarm 2. Find the 'paymentService' entry and do a POST of the transaction to that service. We have been toying with changing that entirely and getting rid of the .well-known URL and instead serving a JSON-LD document outlining all of the domain services available at a particular URL. So that .well-known/payswarm document above would instead be delivered when you hit the root URL for the domain, so the process would be: 1. Hit the root domain of the payment processor, for example: https://dev.payswarm.com/ and content negotiate for JSON-LD, TURTLE, NQuads, etc. That would return the 'paymentService' URL. The benefit of this approach is that you can embed the services in the HTML document as JSON-LD or RDFa, or you can content negotiate for it. You also don't have to have special .well-known URL registries and the solution can be re-used for any sort of REST API web services on the site (and extended dynamically instead of having to go through IETF or W3C). Thoughts? > 2. Can I use PUT as well as POST? I think we decided on POST because you're creating a new transaction in the system, whereas PUT would mainly be used for existing transactions (or in systems where you know what the final transaction URL is going to be. > 3. Is signature mandatory, e.g. if user is already authenticated, > perhaps it's not always needed? Signature isn't mandatory if the user is authenticated. Keep in mind that PaySwarm allows 3rd parties to submit transactions on your behalf, and in that case, there'd be two signatures necessary: 1. The signature on the transaction that was authorized by the sender of the value. 2. The signature on the transaction request that lets the system know who's submitting the transaction and whether they have the authority to do so. This 3rd party submission scenario is useful for escrow, disconnected-operation, delayed payments use cases. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: High-Stakes Credentials and Web Login http://manu.sporny.org/2014/identity-credentials/
Received on Wednesday, 19 November 2014 14:49:01 UTC