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. 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]>: > 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) > > 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]> 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]>> wrote: >> >>> >> >>> To me this sounds more like a W3C activity than an IETF activity. >> >>> Jim >> >>> *From:*jose [mailto:[email protected]]*On Behalf Of*Anders >> Rundgren >> >>> *Sent:*Wednesday, March 18, 2015 10:41 PM >> >>> *To:*[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]> >> >>> https://www.ietf.org/mailman/listinfo/jose >> >> >> > >> > _______________________________________________ >> > jose mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> > > _______________________________________________ > jose mailing list > [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
