1
edit
Changes
no edit summary
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.)
