Sent from my iPhone
> On Apr 14, 2015, at 1:36 AM, Anders Rundgren <[email protected]> > wrote: > >> On 2015-04-14 05:20, Nat Sakimura wrote: >> I think this is an interesting idea. >> One of the disappointment of webcrypto, if I am not mistaken, is that they >> confined themselves > > too narrowly that it did not define the APIs that can leverage, for > > example, a secure element. > > There are many ways of expressing why it didn't work out as anticipated. IMO, > if existing > applications had been "decomposed", it had been more obvious that they work > because they > don't expose sensitive cryptographic APIs to arbitrary Web code. I.e. > there's a reason why > we after 20 years with secure payment cards still can't use them on the Web! > > I'm thinking about a system where locally "Trusted Applications" are > "talking" with > untrusted Web pages: > https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf > A predecessor is already available in the Chrome browser. > > It turned out that the very same concept could probably also be applied to > devices > connected with NFC/Bluetooth: > https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf > > Anders > > >> If a discussion here at IETF would stimulate the discussion there as well, >> it would benefit the community, IMHO. >> >> Nat >> >> 2015-04-11 19:03 GMT+09:00 Samuel Erdtman <[email protected] >> <mailto:[email protected]>>: >> >> Hi, >> >> I think this could be interesting, don´t know if a standards for this >> should be written under IETF or somewhere else, but I can share a few use >> cases we have at neXus where we need to use platform specific capabilities. >> And a bit on how we currently solve it. >> >> * Smart Card signatures >> In e.g bank transactions signatures are desired. We develop a middleware >> with this support (has been used for the Swedish eID for many years), we >> have historically created plugins to the comunication between the browser >> and the middleware. But as NPAPI is going away we have now created a new >> architecture that relies on server component that makes it possible to open >> up a communication channel between the browser and the middleware. >> >> * RFID coding >> This is kind of like printing, when creating cards for physical access >> systems (PACS) some data has to be coded in the card or read from it as it >> is printed (Mifare Desfire etc.), for this we have a SDK/application that >> runs locally but the card management system runs in the browser. The >> communication is currently done with a socket connection to localhost, it >> works well but has some clear drawbacks e.g. TLS. >> >> * Signature pad >> * Fingerprint recording >> * Document scanning >> When doing identity management we collect data about the user when >> enrolling. Once again it is not possible to collect all this data from a >> browser i.e. we need something running locally, and we need to communicate >> with it. Currently we do a connection to localhost. >> >> * End point integrity >> We have a client application that is loaded to validate that that >> platform (OS, antivirus etc.) is updated before allowing the user to connect >> to the corporate network. And when the user is logged out it helps the user >> to clean upp downloaded files so that sensitive data gets minimal exposure. >> (this solution relies on java applet and activeX) >> This is similar to what NEA and SACM are working on, but their definition of end point is not scoped to just a browser or application. For this interested in this question, please take a look at SACM and proposed solutions can be reviewed there. They have an open call for proposals and recognize that different solutions will be needed depending on re platform being assessed. Best regards, Kathleen >> All of these use cases would benefit form a standardised way of >> communicating from the web browser (JavaScript) with a locally installed >> application. >> >> Best Regards >> Samuel Erdtman >> >> >> >> >> On Fri, Mar 20, 2015 at 8:30 AM, Hannes Tschofenig >> <[email protected] <mailto:[email protected]>> wrote: >> >> I like the proposal Anders put forward. >> Doing some work in the IETF in that area might not be a bad idea to >> stimulate discussions. >> >> Ciao >> Hannes >> >> >> On 03/20/2015 06:49 AM, Anders Rundgren wrote: >> > On 2015-03-19 19:15, John Bradley wrote: >> >> It sounds like WebCrypto or something more related to it. >> >> http://www.w3.org/2012/webcrypto/ >> > >> > I would rather characterize this as the opposite to WebCrypto >> since the >> > referred schemes >> > all are based on the idea that "The Web is not enough". >> > >> > That is, the Web needs (as proven any number of times), to be >> extended >> > with its more >> > powerful native/platform companion for a lot of reasons including >> access >> > to platform- >> > resident keys as well as breaking away from the crippling SOP >> notion. >> > >> > The W3C does not appear to be a suitable home for such an effort, >> they >> > rather prefer >> > continuing the so far pretty unsuccessful efforts DUPLICATING the >> native >> > level into >> > the Web [1], instead of recognizing the power of COMBINING these >> worlds. >> > >> > Cheers, >> > Anders >> > >> > 1] >> https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/0000.html >> > >> >> >> >> >> >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad <[email protected] >> <mailto:[email protected]> >> >>> <mailto:[email protected] <mailto:[email protected]>>> >> wrote: >> >>> >> >>> To me this sounds more like a W3C activity than an IETF activity. >> >>> Jim >> >>> *From:*jose [mailto:[email protected] >> <mailto:[email protected]>]*On Behalf Of*Anders Rundgren >> >>> *Sent:*Wednesday, March 18, 2015 10:41 PM >> >>> *To:*[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> >>> *Subject:*[jose] Charter Proposal: "Trusted Code" for the Web >> >>> Trusted Code for the Web >> >>> >> >>> >> >>> Existing security-related applications like authentication, >> payments, >> >>> etc. are all based on that a core-part is executed by statically >> >>> installed software that is supposed to be TRUSTED. >> >>> >> >>> Since web-based applications are transiently downloaded, >> unsigned and >> >>> come from any number of more or less unknown sources, such >> >>> applications are by definition UNTRUSTED. >> >>> >> >>> To compensate for this, web-based security applications currently >> >>> rely on a hodge-podge of non-standard methods [1] where trusted >> code >> >>> resides (and executes) somewhere outside of the actual web >> application. >> >>> >> >>> However, because each browser-vendor have their own idea on what >> is >> >>> secure and useful [2], interoperability has proven to be a major >> >>> hassle. In addition, the ongoing quest for locking down >> browsers (in >> >>> order to make them more secure), tends to break applications >> after >> >>> browser updates. >> >>> >> >>> Although security applications are interesting, they haven't >> proved >> >>> to be a driver. Fortunately it has turned out that the desired >> >>> capability ("Trusted Code"), is also used by massively popular >> music >> >>> streaming services, cloud-based storage systems, on-line gaming >> sites >> >>> and open source collaboration networks. >> >>> >> >>> The goal for the proposed effort would be to define a vendor- and >> >>> device-neutral solution for dealing with trusted code on the Web. >> >>> >> >>> >> >>> *References >> >>> * >> >>> 1] An non-exhaustive list include: >> >>> - Custom protocol handlers. Primarily used on Android and iOS. >> >>> GitHub also uses it on Windows >> >>> - Local web services on 127.0.0.1. Used by lots of services, >> from >> >>> Spotify to digital signatures >> >>> - Browser plugins like NPAPI/ActiveX. Used (for example) by >> millions >> >>> of people in Korea for PKI support but is now being deprecated >> >>> - Chrome native messaging. Fairly recent solution which enables >> >>> Native <=> Web communication >> >>> >> >>> 2]https://code.google.com/p/chromium/issues/detail?id=378566 >> >>> >> >>> _______________________________________________ >> >>> jose mailing list >> >>> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> >>> https://www.ietf.org/mailman/listinfo/jose >> >> >> > >> > _______________________________________________ >> > jose mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
