- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 29 Oct 2014 07:48:03 +0100
- To: helpcrypto helpcrypto <helpcrypto@gmail.com>, public-web-security@w3.org
Apple didn't try to retrofit the old devices when they created Apple Pay. Although there are business models involved as well, Apple would also have created huge problems for banks (and users) if everybody have had to implement (and use) a "fallback" solution as well. I.e. you should IMHO not expect PKCS #11 and existing smart cards to become a part of the plot because they were simply put not designed for the web. Regards Anders Rundgren On 2014-10-28 09:09, helpcrypto helpcrypto wrote: > Hi > > > Don't know if I'm late, but as nvdbleek proposed [1], we are truly interested in a web-document signing approach. > > Actually we suffer Java applets, and dream about a Javascript alternative (like Webcrypto) but with the possibility of looking for an specific key (even at specific card). > > So, something like findCertificate(token,filter) where filter can be subject, issuer or a combination of them would be great. > > Regarding to population, we have several smartcards from different manufacturers which -sadly- use different PKCS#11, so generateKey(token,keyinfo) could also be interesting. > > Finally, we do batch signing, where one PIN let the user sign a batch of documents (currently hashes), so this feature is also very interesting. > > > With these constraints in mind, we propose -more or less- the following API: > > - optional getToken to retrieve a token handle to work with. This could be also issues to secure communications between server and client, using SM and/or component certificates like some eID. > - getCertificate(filter) which can allow us to filter and show a "filtered dialog". some exaples: fingerprint, issuer, subject, keyUsage...using a json-like filter which allows combination seems to be much better. > > Signatures are made in 3 steps: > - init: needed initialization > - add: invoked for each document we want to sign. the document is sent to the component/browser and stored internally > - final: a final "you are going to sign this" dialog is shown. It will be possible to even show a preview of the documents (pdf,xml+xslt,...) using other plugins. asks for pin > > Of course, all this must be Js asynchronous > > We usually do XAdES or PAdES signing. probably a signed js library or something lika that could be great to extend usage. > > > This is what actually our applet does, and its the use case we would live to have on Webcrypto. > > Don't hesitate to contact me if you want to discuss this in deep. > Regards > > > [1] http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html >
Received on Wednesday, 29 October 2014 06:48:47 UTC