- From: David Dahl <ddahl@mozilla.com>
- Date: Thu, 24 Nov 2011 05:38:27 -0800 (PST)
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, public-identity@w3.org, Harry Halpin <hhalpin@w3.org>
----- Original Message ----- > From: "Anders Rundgren" <anders.rundgren@telia.com> > To: "Harry Halpin" <hhalpin@w3.org> > Cc: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, public-identity@w3.org > Sent: Thursday, November 24, 2011 5:40:15 PM > Subject: Re: Drastically cutting primary features [was Re: Last call for public comments on Web Crypto charter] > IMO, the division between simple and difficult goes between a > domain-oriented crypto system and a traditional unrestricted ditto. > > In a domain-restricted crypto system everything happens between a > specific user/browser and a specific relying part/issuer application. > Privacy-wise there are no issues and security-wise screw-ups are > limited to exactly these two parties. > Exactly. This is important as we do not want to provide globally-usable keys as a way to prevent global screw-ups. > I think it is time for the DomCrypt guys to chime-in and say if > this description is wrong or not. Phrases like "we must support > smart cards etc in the future" has no room in a charter because > that has to proved with respect to *feasibility*. Oracle has > smart card support in Java (javax.smartcardio.*) which nobody > uses because it simply doesn't work. I never intended to support smart cards or hardware of any kind in a first iteration. I think hardware support will greatly increase the scope and complexity, which is not a good starting point. I'd rather start with a very easily scoped set of work for implementors. Cheers, David
Received on Thursday, 24 November 2011 13:38:55 UTC