Hello, On Jun 1, 2010, at 12:50 , João Poupino wrote:
> You could go the eToken 72K route now - and it will probably work fine for > you - but in the future, you may have issues with OpenSC because we may > change stuff that will break current cards loaded with the Muscle applet. > This will not be very nice, especially since SafeNet will make the applet > permanent on the card... The best of course would be to get clean engineering version tokens, which will leave you the freedom of managing your tokens the full cycle. > On Jun 1, 2010, at 9:11, Jonathan SEMCZYK wrote: >> >> I like those eToken, I found them pretty small and you cannot open the token >> without breaking it. True, the same reason why I like actual tokens not the sim+adapter solution. For example there's the real "will it survive in a keyring, in the pocket" test which good tokens survive without problems. >> >> The thing with SafeNet is that they are only allowed to sell locked tokens >> (engineering are for development use only, you can get only few samples). If >> the Applet changes I will not be able to reload it myself. And I'll probably >> have to buy new tokens. >> Our reseller can sell us a basic pack of 10 tokens, not very expensive, >> around 30 euros the token. They can sell customized tokens in batches of 10 if you send them a cap file? 10 tokens 300 euros? OK. >> >> Le 31/05/2010 19:25, João Poupino a écrit : >>> IMHO, the MuscleApplet is not quite ready for massive production deployment >>> yet. It is being actively improved upon, and at this time, key ideas are >>> still being discussed. We believe it could play an important role with >>> Javacards, but not in its current state, mainly because there are ideas >>> that should solidify first. This will probably imply changes to both the >>> applet and OpenSC. >>> >>> Again, this is just my humble opinion. Martin, who has recently been the >>> main driving force behind the evolution of the Muscle applet, should chime >>> in on the matter and give us his insight :) >>> >>> In the meanwhile, you can find a CAP file and a summary of some of the >>> ideas being discussed in [1]. I expanded the page with some more information and personal observations. Maybe a philosophical explanation why JavaCards are (IMHO) good and somewhat superior to "vendor cards" (they won't be "discontinued" in the same manner, you have full control and open source software on the card side as well, you can create flexible and innovative features etc) should be written as well. Right now I'm trying to get a in-house "upgrade" (or downgrade, depends on your viewpoint) of the MuscleApplet cleaned to a state where it could be pushed to github. The "problem" of OpenSC is that it is hard to find a good balance between "works well for me" and "works well in an universal way", which means that generalizing special handling is difficult. The important part is that MuscleApplet is not a static card, meaning "here is the applet, it is frozen, we have support for it in OpenSC, nothing else to do now" but it should be brought up to date as well, and evolve with OpenSC (or other tools) as the muscle framework, as was correctly noted before, is almost dead these days, without major systematic improvements in past years. If there are people out there who would be interested in trying it out and helping out, I can send a free JavaCard to people interested in development and/or testing. It might require a little bit deeper knowledge of the smart card field and it might not be an easy ride in the beginning, but I'm sure that in the long run it is a very viable and good option. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
