W3C home > Mailing lists > Public > public-usable-authentication@w3.org > June 2006

Re: Draft charters available; please comment.

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 22 Jun 2006 10:12:41 +0200
To: Amir Herzberg <amir.herzberg@gmail.com>
Cc: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>, public-usable-authentication@w3.org
Message-ID: <20060622081240.GQ3447@lavazza.does-not-exist.org>

On 2006-06-22 09:29:58 +0300, Amir Herzberg wrote:

> >>   - Form Annotations for HTTP Authentication.
> >>     http://www.w3.org/2005/Security/htmlauth-charter
> >>    
> >>     Think of this as form-filler support on steroids, as
> >>     sketched in late May on this list.

>>I'm less excited about this one, but it could be that I
>>don't have the full vision. What irks me about this one is
>>that passwords aren't the only thing. In fact, they're not
>>even always the most useful thing.  Other PII like credit
>>card numbers, SSN, etc. are still ripe forms of attack.

> Some of this subject is indeed not limited to passwords, and
> I think the charter should be modified to allow for other
> sensitive data entered by web users (typically on forms).

Could you elaborate a bit more on this idea?

I can see how to do a limited scope when the goal is what you
describe in your next paragraph -- keep passwords under control
(and maybe site-specific), create hooks for browser-side
password management, create hooks for launching nice and secure
user interfaces on the browser side, even divert passwords
entered into forms away from POST and into protocol-level
authentication.  That's basically the current proposal.

It's less clear to me what a *limited* scope for more general
annotations could look like, and how to design that scope
without venturing into the broader space of privacy-enabled,
user-centric, etc identity management. (Annotating forms with,
say, the P3P base data schema [or any other vocabulary for PII]
would certainly be interesting and might open up all kinds of
exciting things -- I'm just not sure it's where we should be
going right now and right here.)

For passwords and the like, the assumption should be that they
are, generically, different for different sites.  (Even if
users may currently just take "1234" for everything.) Hence, if
software can make it easy to use passwords with the sites that
they belong to, and a bit harder to use them with the sites
that they don't belong to, then we already gain quite a bit.

Tying forms to protocol-level authentication would be an
additional benefit that the kind of annotations that the draft
charter describes can enable without much additional hassle.

>>So what I don't get about this one is "why"? If it's "just"
>>to provide an excellent foundation for exploring solultions
>>that need this feature, then I do get that, because there's
>>research that's having problems with this. I'm missing why
>>if protecting passwords is the question, Digest isn't the
>>answer. It may be obvious to pretty much everyone else, so
>>apoligies if it is.

> The problem is not, imho, the (bad) use of passwords on the
> clear. The problem is mainly phishing - people entering
> passwords into wrong sites - combined with dictionary
> attacks (people using weak passwords) and the infamous
> password-reuse problem (using same password for multiple
> sites).

> I think we have good solutions here and one of the missing
> components is browser support - for identifying these
> fields, for changing to a software-generated password
> automatically, and for the UI (which should be integrated
> with the secure chrome work item).

Precisely.

Regards,
-- 
Thomas Roessler, W3C   <tlr@w3.org>
Received on Thursday, 22 June 2006 08:12:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC