Thanks. I will have a look at. Cheers,
Nat 2015-04-14 22:17 GMT+09:00 Kathleen Moriarty < [email protected]>: > > > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
