Difference between revisions of "Mozilla Proposes"

From IIW
Jump to: navigation, search
(Undo revision 3208 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://ycybesav.co.cc Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page]=
=[http://ycybesav.co.cc CLICK HERE]=
Issue/Topic:  Mozilla Proposes:
Issue/Topic:  Mozilla Proposes:

Latest revision as of 15:56, 3 February 2011

Issue/Topic: Mozilla Proposes:

Monday – Session 2 - A

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

Convener: Dan, Mike, Ragavan

Notes-taker(s): Dan Mills

Tags for the session - technology discussed/ideas considered:

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

Lots of questions about how this is different from just a password manager?

  • it is an extension of password management, and an abstraction of ui
so that different auto mechanisms can be used.

* password managers try to guess how a site works, account manager
aims to be completely deterministic in it's behavior.

  • account manager includes ways for the site to advertise to the
browser multiple ways of interacting (e.g. Passwords vs http aith vs
openid), as well as current state (signed in, not), which would
otherwise need to be scraped.

How will this work with other password management extensions?

  • Apis need to be included so that extensions can make use of account manager.

How is this better than something 401 related for intranet sites? 
* allows for disclosure of endpoints and status without a 401

  • goal is to interop with http auth, not force it on everyone.

Are you introducing new http headers?

  • yes, we are using the Link header, and defining a new one for the
website to advertise to the browser the current user signed-in status.

How do you behave if you get a 401 with an unknown authentication scheme?
401 vs. 200 discussion?

Where will this code live? Will it be part of platform? Firefox? How
will this affect derivative works?

  • not clear 100% how much will be part of the embeddable gecko vs in firefox.

  • the protocol will of course be open, and the firefox I pleme tat ion
will be open source.

Why did you restrict to just username/secret?

  • I'd/secret negotiation is for the username-password-form profile
only; other profiles could do something different (but would need ui

Why didn't you use html markup for registration?

  • still a possibility, feedback welcome.  We felt like it would be
 more error-prone.

If I don't support registration, can I just put a URL in the AMCD?

Can the site specify a password policy? Sites seem to truncate long
auto-generated passwords? 
* yes, feedback welcome on whether it is sufficient.

Preventing against malicious attackers flooding the registration flow. 
* need to think about this one, open problem.

How does this fit with OpenID Connect?

  • hope is that the protocol pieces of opened connect can be managed
using the account manager ui.

Can you to a well known location to get a 401 that also incorporates
the TLS client cert piece?

* interesting idea, needs more thought.

Companies holding a lot of identities need to get off
username/password to access tokens because of phishing attacks. They
like OAuth, because it is based on the WWW-Authenticate header.

Account manager meet-up at the Mozilla offices in downtown Mountain
View this Friday afternoon, see the Account Manager page for details:
 HYPERLINK http://www.mozilla.com/firefox/accountmanager