Difference between revisions of "Secure Web Auth"

From IIW
Jump to: navigation, search
(Undo revision 3150 by Igiwydijok (Talk))
 
Line 1: Line 1:
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
=[http://acisabukody.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
 
----
 
=[http://acisabukody.co.cc CLICK HERE]=
 
----
 
</div>
 
 
'''Session:''' Tuesday – Session 3 - L
 
'''Session:''' Tuesday – Session 3 - L
  

Latest revision as of 13:02, 7 February 2011

Session: Tuesday – Session 3 - L

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Convener: Yutaka OIWA

Notes-taker(s): Yutaka OIWA, Tatsuya HAYASHI

A. Tags for the session

technology discussed/ideas considered:

  • Secure Web Authentication

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps

Presentation is available at: https://staff.aist.go.jp/y.oiwa/publications/2010-IIW10-MutualAuth-P.pdf

Questions from the floor:

(identities of questioners wanted!)
Q(___) How about the header format?
A. The protocol uses a format based on RFC 2617, compatible with existing protocols.
Q(___) Scalability issues
A. The protocol supports a domain-based single-sign-on (e.g. *.yahoo.com).
Cross-domain authentication might be useful with integration to existing authentication mechanisms (e.g. SAML, OpenID etc.)
Q(___) Compatibility with existing applications and their migration
A. It requires a small change to existing applications.
It includes several extensions to existing HTTP auth mechanisms, which enables migration of current (form-authentication-based) applications to our scheme without changing the whole design of website (current Basic/Digest auth has difficulty on user-experience compatibility). For example, it includes support for guest-user support (optional authentication), server-initiated forced logout, redirection of unauthenticated users to dedicated log-in pages, and others.
Q(___) Compatibility with existing browsers
A. Browsers must also be extended. We already implemented it on Mozilla codebase and see how much modification needed.
Q(___) How to migrate from or co-exist with existing auth, such as Form auth or Basic?
A. Application frameworks can support parallel support with Form-based auth (because existing browsers simply ignore our WWW-Authenticate headers). Parallel support with Basic auth may need some additional functionality for negotiations (HTTP spec supports two or more WWW-Authenticate headers at the same time, but it does not work well on existing code).
Q(___) Standardization issues and schedules
A. We are working on IETF to making this a WG issue. Originally handled in HTTPBIS WG, now under OAuth WG temporarily. We maybe need a new WG for this and related issues. We want it within around 1 year.
Q(___) Real-world experiences, deployment and field-tests.
A. We’ve done a field test on “Yahoo! Japan Auction Trial” website. We’ve got a feedback on deployability and compatibility with existing web applications. For scalability and user-experience we may need more testing in a near future.