Mozilla Proposes
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 implemented)
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
