Re: W3C Web Identity Standardization Woes

On 2012-02-14 07:48, Henry B. Hotz wrote:
> 
<snip>
> If you don't believe in standards, then what are you trying to accomplish here?

I believe in standards but not in standards that claim to do things they
weren't originally designed for which in this particular case includes
"financial transactions".

My interpretation of the current charter + the input documents is that
there are two *independent* work items.  If this interpretation is right
I would suggest taking on one of them rather than mixing apples and oranges.

I'm actually quite interested in financial transactions through digital signatures,
maybe even as a standardization item.  In fact, I have suggested this numerous of
times before to W3C officials.  Anyway, the current signature specification is not
clear enough, not even for a charter.  It appears to me that the interest in such
a facility in this list is marginal which makes the original DOMCrypt suggestion
a better choice as a standardization item.

<snip>

Anders
http://webpki.org/papers/wasp/wasp-tutorial.pdf
http://webpki.org/papers/wasp/wasp-faq.html


> 
>>>> There are
>>>> no surefire successes in this space and I wish you luck.
> 
> ???
> 
>>>>>> On 02/08/2012 06:30 AM, Anders Rundgren wrote:
>>>>>>> IMO smart
>>>>>>> cards using non-domain-restricted credentials such as PIV must not be exposed
>>>>>>> on the web; they can only be used by trusted applications such as TLS.
>>>>>>>
>>>>>>> Anders
>>>
>>> I have absolutely no idea what you are trying to say here. 
>>
>> Well, from the discussions 2011 it seems that you are not alone :-(
>>
>> If you take a look a Microsoft's CertEnroll you have a system which
>> is broken due to a misunderstood web security and privacy concept.
> 
> There's an unfortunate amount of stuff which is broken because the designers did not understand the underlying trust model they were using.
> 
>> 1) I'd hardly call TLS a "trusted application";
>>
>> The TLS code is supplied by the browser vendor which differs in
>> trustworthiness from arbitrary transient code from a web-site.
> 
> OK, the browser is an application which implements the TLS protocol.  The other un-trusted applications you're referring to are web-apps.  True?
> 
>> 2) A PIV card is a well-defined client credential, with good security properties.
>>
>> Yes, but if you let arbitrary web code access it you won't be able
>> maintaining these properties.
> 
> So, IIUC you are concerned that a web crypto standard would provide free and open access to the client identity and use of its private key.
> 
>> Obviously, if someone can *otherwise* break in to the machine it's 
>>> plugged into, it can be at least temporarily hijacked.
>>> Is that what you mean by "exposed on the web"?
>>
>> No, see above.
> 
> My interpretation of your earlier answers suggests "yes".  If a JavaScript crypto extension allowed arbitrary downloaded JavaScript "free and open access to the client identity and use of its private key", then it would inherently be a way to "*otherwise* break in to the machine".
> 
> As they said on Ghostbusters, that would be "bad".
> 
> I'm not hard over that it would necessarily always be bad, but would need some serious convincing that restrictions are strong enough and simple enough to be effective.
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> 
> 
>

Received on Tuesday, 14 February 2012 08:57:28 UTC