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

On 2015-03-18 14:51, Hannes Tschofenig wrote:
> Hi Anders,
>
> what deliverables do you think this group should produce?

Hi Hannes,

There are currently at least four (!) entirely different ways to invoke "trusted code" so I guess
the first step would be to characterize them so that it gets easier to select which one to go with.

The existing schemes are:
- Custom protocol handlers.  Primarily used on Android and iOS.  GitHub also uses it on Windows
- Local web services on 127.0.01.  Used by lots of services, from Spotify to digital signatures
- Browser plugins NAPAP/ActiveX.  Used (for example) by 25M people in Korea but is now being deprecated
- Chrome native messaging.  Fairly recent solution which enables Native <=> Web messaging

There may of course be a new scheme as well.

The end-result should be a deliverable that describes interfaces and deployment recommendations.
The goal is that the deliverable eventually should be a standard feature in browsers.

Ciao,
Anders

>
> Ciao
> Hannes
>
> On 03/18/2015 01:58 PM, 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.
>>
>> 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 14:56:26 UTC