From MozillaWiki
Jump to: navigation, search

In scope for this session were stateless profiles (such as HTTP Auth) and generally looking at the protocol to identify anything that might limit our choices in the future. We seeded it with a couple of questions/uses:

  • What should the AM role be in challenge-response scenarios?
  • Client certs
session notes

Future workgroup

  • John Smith@Verisign
  • Yutaka OIWA@AIST Japan
  • Tatsuya HAYASHI@lepidum Japan

First, Yutaka presented a UI and protocol prototype that resembles account manager in a few ways.

  • Prototype recognizes supporting sites login pages.
  • Prototype embeds user password into browser chrome.

Need to identify ways in which Yutaka's protocol & UI work could be integrated with Mozilla account manager work.

What we may need:

(1) Multi-factor authentication, For example,

  • One-time password tokens + user password,
  • client certificates,
  • Flickr, OAuth style tokens.

(2) Selection mechanism for multiple authentication tokens, For example,

  • a user has two different certificates which could be accepted by a site.
  • Privacy/confidentiality Issues: Don't send out identities to unverified parties.

Agreement of the sub-group:

The authentication technologies and techniques vary greatly. It is important to modularize and separate the authentication portion from session & identity information. We separate these ideas, but final assertions & UI display should correctly reflect a binding of session-identity-authentication techniques used. The binding should be represented in a similar manner to current server authentication, e.g.

  • Icon/coloring on chrome displayed,
  • Clickable/mouse-over for detailed information.

Detailed UI should show branding & privacy information about

  • who did the authentication
  • what kind of authentication was done
  • privacy info for the data exchanged
  • How to support multi-page/multi-step authentication/registration?
P.S. from Yutaka OIWA

In the session we mainly talk about integrating various authentication technologies (including client certificates, Mutual authentication and two-factor auths).

Regarding integration of HTTP Basic authentication to the Account Manager, we performed some analysis about integration of HTTP authentication with non-modal interfaces. As a result, our Mutual-authentication proposal contains several extension to the current HTTP authentication mechanism. It is actually not specific to our Mutual authentication, and it may be very useful also for Basic and Digest authentications with the Account Manager.

(Now we are going to separate such extension part from the Mutual authentication and to make a separate Internet Draft on it. If you are interested to integrate HTTP auths to the Account Manager, I think our group can contribute some inputs to your design, or even we can work together on it.)