W3C home > Mailing lists > Public > public-web-security@w3.org > March 2015

Re: Charter Proposal: "Trusted Code" for the Web

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Wed, 18 Mar 2015 14:50:09 +0100
Message-ID: <55098291.3070008@gmail.com>
To: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>
CC: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>
On 2015-03-18 13:58, GALINDO Virginie wrote:
> Anders,
>
> I don’t see how you can state that this is a replacement of the smart card effort, without even consulting the companies supporting it.

Hi Virginie,

Gemalto have been offered *free consulting* on this topic ("smart cards for the web") but turned it down.

BTW, this project also makes Microsoft's certificate enrollment scheme redundant.

How I can rightfully claim all this?  Because I have researched existing products and uses.
In fact, quite a bunch of the people you met at the WebCrypto.Next F2F are working with this kind of solutions since years back.

There are also folks in the W3C Payment CG who depend on such solutions not to mention DropBox, Spotify and GitHub.

What's missing is an interoperable standard.

Regards
Anders Rundgren

>
> Virginie Galindo
>
> Gemalto
>
> *From:*Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
> *Sent:* mercredi 18 mars 2015 06:15
> *To:* public-web-security@w3.org
> *Cc:* Mike West; Anne van Kesteren
> *Subject:* 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 known sources, such applications are by definition UNTRUSTED.
>
> To compensate for this, web-based security-related applications currently rely on a hodge-podge of non-standard methods where trusted code is located somewhere outside of the actual web application.
>
> Since each browser-vendor have had their own idea on what is secure and useful, interoperability has proven to be a major hassle, including the fact that the quest for locking down browsers (in order to make them more secure), also tends to break applications after browser updates.
>
> Although security-related 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 services 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.
>
> -----
>
> This proposal is also supposed to be a replacement for a possible  "smart cards for the web" effort
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
Received on Wednesday, 18 March 2015 13:51:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 March 2015 13:51:01 UTC