- From: Nico Williams <nico@cryptonector.com>
- Date: Wed, 15 Jun 2011 09:35:41 -0500
- 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. Nico --
Received on Wednesday, 15 June 2011 14:36:05 UTC