Re: Trusted Browser Component (Re: Action 213: write a lightning proposal on wiki)

It seems like we dropped this one due to lack of interest.  It's,
however, not clear to me that everything covered here is also part
of Tyler's PII Editor Bar, so I'd like us to have another very
careful look.

The main use case would be entry of credentials for protocols that
use Zero-knowledge password proofs, thereby responding to one of Sam
Hartman's key requirements.  Note that this use case is not yet
reflected in the Note; that would have to change.

It might be that the first public working draft just includes a
segment in the table of content and an editor's note "we expect to
drop such and such in here later on."

Rachna, please share what your plans are with this proposal.

Tyler, please indicate whether you can take care of a zkpp-related
use case for the note.

Thanks,
-- 
Thomas Roessler, W3C  <tlr@w3.org>







On 2007-06-11 00:41:36 +0200, Thomas Roessler wrote:
> From: Thomas Roessler <tlr@w3.org>
> To: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
> Cc: rachna.public@gmail.com, public-wsc-wg@w3.org
> Date: Mon, 11 Jun 2007 00:41:36 +0200
> Subject: Trusted Browser Component (Re: Action 213: write a lightning
> 	proposal on wiki)
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> (This thread is kind of relevant to ACTION-257 -- mostly adding this
> link since tracker was actually where I started searching for this
> thread. ;)
> 
> So, reviewing the proposal, I think the key aspects that I see are:
> 
> - Log in to some set of web sites for which credentials are known
>   through a simple gesture, thereby forcing phishing sites to cause
>   a disruption in the user's browsing process.  This sounds like it
>   might be a pretty effective defense against impersonation types of
>   attacks.
> 
> - Control this functionality through some shared-secret based widget
>   that can be recognized.
> 
> - A neat association process to make people say what they want to do.
> 
> In some places, you seem to mention "this login protocol."  I gather
> that this might be any protocol which does not transmit passwords
> over the wire, but that's not clear to me.  Mind clarifying?
> 
> Part of the value proposition of the proposal seems to be that the
> "trusted browser component" would enable users to enforce use of a
> zero-knowledge password proof [e.g., defend against the "please
> enter your password here" attack that's of course possible].  I
> wonder how effective that actually is -- i.e., will people simply
> enter their passwords when a normal form occurs --, and more
> generally, what the interaction would be with traditional login
> mechanisms (RFC 2617, forms+cookies).
> 
> My worst-case hypothesis would be that, whenever people touch
> passwords, they can be persuaded into entering them.  It's not
> obvious to me what the right conclusion would be from that: Invoking
> the association process?  Or invoking some "legacy association
> process"?  *Hiding* from the user whether the secure or the insecure
> protocol are used, and making decisions about that under the hood?
> 
> Just falling back to current behavior somehow seems like the wrong
> fallback here.
> 
> Cheers,
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>
> 
> 
> 
> 
> 
> 
> 
> On 2007-06-08 12:24:48 -0400, Mary Ellen Zurko wrote:
> 
> > "The user shares a secret with the Trusted Browser Component. The shared 
> > secret may be an image selected by the user, or can be another type of 
> > secret (e.g., text or audio) to meet accessibility requirements. The 
> > shared secret creates a "trusted path" between the user and the Trusted 
> > Browser Component. Examples of user customized website and browser 
> > interfaces include [4], [5] and [6]. "
> > 
> > This part definately seems in scope, and as I mentioned in PIIEditorBar, 
> > Perhaps you can put it into conformance language. 
> > 
> > "The first time the user visits a trusted website or wishes to create an 
> > account at such a website, he must create an association between the 
> > browser and "trusted website"(e.g., the browser may automatically 
> > recognize that this is a website that supports this login mechanism, the 
> > user may be required to perform an action to make an association, the user 
> > may be required to supply an out of band activation code). This step 
> > represents a one-time trust decision by the user (usability testing is 
> > required to determine if users can accomplish this task). This trust 
> > decision can be supported with information supplied by the browser (EV 
> > status, user's history with the website, others' history with the 
> > website). "
> > 
> > Asking users for one time trust decisions is definately in scope (that's 
> > what SSL does today with self signed certs). I'd very much like to see 
> > recommendations abstract enough to support a variety of implementations of 
> > those trust decisions, and some usability testing on the topic, in our WG. 
> > So I'd like to see you carry this part forward as well. 
> > 
> > The Login part also seems phrased to keep it all in scope, and I can see 
> > working with basic password management tools in that context as 
> > alternative examples. 
> > 
> >           Mez
> > 
> > Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
> > Lotus/WPLC Security Strategy and Patent Innovation Architect
> > 
> > 
> > 
> > 
> > "Rachna Dhamija" <rachna.public@gmail.com> 
> > Sent by: public-wsc-wg-request@w3.org
> > 05/24/2007 01:13 PM
> > 
> > To
> > public-wsc-wg@w3.org
> > cc
> > 
> > Subject
> > Action 213: write a lightning proposal on wiki
> > 
> > 
> > 
> > 
> > 
> > 
> > I added a proposal to the wiki.  This opens up a question for the group: 
> > are interfaces to out of scope protocols within our scope?
> > 
> > Trusted Browser Component to Capture User Intention
> > http://www.w3.org/2006/WSC/wiki/TrustedBrowserComponent
> > 
> > 
> 
>

Received on Saturday, 28 July 2007 21:02:31 UTC