- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 06 Feb 2015 16:12:43 +0100
- 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