W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

Re: [saag] [http-auth] [websec] re-call for IETF http-auth BoF

From: Nico Williams <nico@cryptonector.com>
Date: Wed, 15 Jun 2011 09:35:41 -0500
Message-ID: <BANLkTimMzWMdtX-DbkbB0P3GMpG-znSzzA@mail.gmail.com>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Cc: "KIHARA, Boku" <bkihara.l@gmail.com>, public-identity@w3.org, http-auth@ietf.org
On Wed, Jun 15, 2011 at 9:32 AM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> 2011/6/15 Nico Williams <nico@cryptonector.com>:
>>> * a method that hands over a password (or a password-equivalent)
>>> * a method whose UI can be imitated by malicious sites.
>> The protocol and UI are not that closely related.  I can't think of
>> any method that satisfies the first requirement that couldn't have a
>> secure UI.
> How about a simple form-field extension which
> encrypts some password with timed challenges?
> OK, but your point suggests the following rephrasing:
>  * a UI which can be imitated by malicious sites.
> Although they are not closely related, but we cannot completely
> ignore the UI issues . I think that protocol designs
> should, in some extent, consider how such UI is to be provided
> (especially when and how they are kicked in). How about it?

I think what you want is to say that the user agent must implement a
secure UI, or that it must integrate with the platform's secure UIs,
if any.  The UI is quite distinct from the authentication protocol.

I agree that a UI that cannot be imitated is a good and desirable
thing, but as long as full-screen applications are allowed you'll need
a secure attention sequence instead.

Received on Wednesday, 15 June 2011 14:36:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC