- From: Harry Halpin <hhalpin@w3.org>
- Date: Sun, 09 Feb 2014 00:43:23 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Frode Kileng <frodek@tele.no>, Web Payments <public-webpayments@w3.org>
- Message-ID: <52F6C11B.8020202@w3.org>
On 02/08/2014 07:23 PM, Melvin Carvalho wrote: > > > > On 8 February 2014 19:07, Harry Halpin <hhalpin@w3.org > <mailto:hhalpin@w3.org>> wrote: > > On 02/08/2014 06:11 PM, Melvin Carvalho wrote: >> >> >> >> On 8 February 2014 17:29, Harry Halpin <hhalpin@w3.org >> <mailto:hhalpin@w3.org>> wrote: >> >> On 02/08/2014 05:04 PM, Frode Kileng wrote: >>> Hi, >>> >>> I just took a look at the new web-payments.org >>> <http://web-payments.org> site. The text at >>> https://web-payments.org/#tech states regarding the Web >>> Payments Community Group: >>> >>> "/also participates heavily in work at the //Internet >>> Engineering Task Force (IETF) <http://ietf.org>//./" >>> >>> After attending IETF meetings for 10 years and closely >>> following the mailing lists for 20 years, this comes as a >>> surprise for me. I've never heard anything about, or from, >>> the CG work and contributions at any physical meetings or >>> any mailing lists. >> >> In particular, the work is also not aligned with the >> WebCrypto API (as Manu rejects algorithm agility) or the JOSE >> specs (ditto I guess). Would appreciate to now what's going >> on there before the Web Payments workshop. As the W3C Crypto >> API (and thus, to an extent JOSE) is being implemented across >> all major browsers, it would behoove Web Payments to be more >> involved and take in input. >> >> >> Im unsure of the issue here. Would it be possible to explain the >> issue with algorithm agility? >> >> FWIW: I have interacted once with the WebCrypto mailing list in >> order to raise an issue, so that it may be feasible for User >> Agents to implement crypto currencies. Right now, most >> implementations have to save private keys in localStorage, which >> is not ideal from a security perspective. I think it would >> reflect well on the W3C crypto group if they were able to adapt >> to the recently growing popularity of cyrpto currencies, even tho >> it was not something explicitly stated in the charter. > > We keep track of requests for algorithms, but since Web Crypto is > being deployed in actual browsers, we cannot deploy algorithms > that do not exist cross-browser, regardless of how popular they > may be in use-cases. > > > Sure, I understand. And that makes sense. > > However, in our most recent charter, it was decided that crypto > currencies were in scope of this group. > > I personally would love to use the W3C Crypto API for this, but it > seems not possible at this time. And I'm unsure if this will change, > or on what time frame. If you can't do your crypto safely in the browser, how do you plan to actually do your crypto? Or you could not use browsers, but relying on plug-ins is not in general a good idea. > > What advice would you give to implementers that are keen to reuse the > work of the W3C, but also would like to start producing > implementations in a reasonable time frame? You should polyfill over the Web Crypto API. You can do that right now. You can also use the developer versions of Chrome and IE also right now. cheers, harry > > >> >> Also, there has been considerable confusion with the Web >> Payments "representing" the W3C at events, when in fact, he >> is not an employee of the W3C nor as the work of the CG been >> approved by W3C - and thanks for toning down the web-page. >> You may want to do the same with the IETF in order to avoid >> similar confusion. >> >> Lastly, how many implementations of the Web Payments work exist? >> >> cheers, >> harry >> >> >>> >>> Could anyone please clarify this statement? >>> >>> If "heavily" can't be supported by facts, please >>> reformulate. Care should be taken to not overselling the CG >>> since it's easily discovered by people who may have an >>> interest in participating in this work. >>> >>> Best regards >>> Frode Kileng >> >> > >
Received on Saturday, 8 February 2014 23:43:37 UTC