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

Re: W3C Next Steps [was Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution]

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 06 Feb 2015 16:12:43 +0100
Message-ID: <54D4D9EB.4060909@gmail.com>
To: Harry Halpin <hhalpin@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>
On 2015-02-06 11:45, Harry Halpin wrote:
>
>
> On 02/05/2015 06:38 AM, Anders Rundgren wrote:
>> On 2015-02-03 23:22, Harry Halpin wrote:
>>> Virginie and Karen,
>>>
>>>     Thanks for the concrete suggestion for what to do next.
>> <snip>
>>> While there was lots of disagreement on the technical details, I think
>>> we all agree on the use-cases that some kind of hardware-backed
>>> cryptographic material would enable need to be part of the Open Web
>>> Platform.
>>
>> Dear Harry,
>>
>> If you use legacy technology like paying with an EMV-card, the card is
>> inserted
>> in a payment terminal which is supposed to be trusted, maybe even
>> certified.
>>
>> This concept (trusted code + UI), is entirely missing from the current
>> submissions.
>>
>> If you to this add the mentioned violations of the web security and
>> privacy model,
>> we seem to have passed the "technical details" stage by a rather huge
>> margin.
>>
>> Most if not all of this apply to the http://www.w3.org/Payments/IG
>> activity as well.
>>
>> Although I'm neither a W3C member, nor a Googler, I suggest that W3C
>> seriously consider
>> getting *unbiased second opinions* from other people to avoid us [all]
>> waiting for what
>> I believe may very well turn up as "nothing".
>
> I understand you may not be paying close attention over the last few
> years - the W3C has brought in outside academic experts to review APIs
> like the WebCrypto API (Graham Steel of INRIA, Kelsy Cairns of WSU, Dan
> Boneh of Stanford) and we'll continue to do so for future efforts.
> Obviously this is not a problem, and we'll bring in more qualified
> academic and neutral experts to review any future proposals in this
> space involving authentication and hardware tokens.

I was probably a bit unclear by I was thinking about concept verification
*before* any kind of publishing.


> Verified JS is a topic we are interested in, but we need to see more
> concrete proposals before going much further.

Yes, that's an option.  It is definitely doable but combined with the
*extremely awkward situation for security HW w.r.t. standards*, it would most
likely only create new problems.  In the end you would require trusted code to be
downloaded from vendor-specific "AppStores" and then the only "webby" thing left would
be HTML5/JS which I guess was one of the reasons to why Google abandoned SysApps.

So unfortunately I don't think *any* of the current approaches will fly which is why
I have (after months of dedicated hard work...), nuked this path in its entirety and begun
working on a different, much smaller and less browser-intrusive approach, which rather
is an *enabler* than a solution itself.

Simple enabling technologies like XHR [1] have historically been good targets for
standardization, often maintaining their value for *decades* (after incremental updates).

Cheers,
Anders

1] http://en.wikipedia.org/wiki/XMLHttpRequest  http://www.w3.org/TR/XMLHttpRequest


>
>     cheers,
>            harry
>
>
>
>>
>> The topic has actually been "on the radar" for quite some time now:
>> https://lists.w3.org/Archives/Public/public-identity/2011Nov/0030.html
>>
>> Best regards
>> Anders
>>
>>>
>>>      cheers,
>>>         harry
>>>
>>>
>>>
>>> On 02/03/2015 05:36 PM, GALINDO Virginie wrote:
>>>> Hi all,
>>>>
>>>> reading the 70 e-mails in this thread and will come back to you with
>>>> a proposal to formalize requests,  use cases, expression of concerns.
>>>>
>>>> Virginie
>>>> (speaking as chair)
>>>>
>>>> ---- Rigo Wenning a écrit ----
>>>>
>>>>> Anders,
>>>>>
>>>>> On Tuesday 03 February 2015 12:42:07 Anders Rundgren wrote:
>>>>>> Although I agree with what you are saying there's a problem:
>>>>>>
>>>>>> None of the stuff you are referring to has ever been directly
>>>>>> connected
>>>>>> to the [UNTRUSTED] web, they are always used with a trusted App + GU.
>>>>>
>>>>> if everybody had already thought about it, my contribution would be
>>>>> noise. My
>>>>> apologies if this is the case. This is a chartering discussion. If
>>>>> thinking
>>>>> about the eGov use case is overkill, we should state that openly and
>>>>> move on.
>>>>> I just want this to be a conscious decision. This enables W3C to
>>>>> respond if
>>>>> asked by the various governments.
>>>>>
>>>>> --Rigo
>>>> ________________________________
>>>>    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.
>>>>
>>>> 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 Friday, 6 February 2015 15:13:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 6 February 2015 15:13:23 UTC