946
edits
Firefox/Projects/AccountManager/Meetup/Analysis: Difference between revisions
Firefox/Projects/AccountManager/Meetup/Analysis (view source)
Revision as of 02:15, 5 June 2010
, 5 June 2010no edit summary
No edit summary |
No edit summary |
||
| Line 66: | Line 66: | ||
A variant of the above could be to allow the password to be changed during the registration flow, but that would require the final confirmation step to return the credentials (username and password both), which sites might not want to do (?). The confirm-registration step need only work once, however, the <token> in the cookie could expire after first use, or have a very short life. | A variant of the above could be to allow the password to be changed during the registration flow, but that would require the final confirmation step to return the credentials (username and password both), which sites might not want to do (?). The confirm-registration step need only work once, however, the <token> in the cookie could expire after first use, or have a very short life. | ||
= Other Ideas = | |||
These are ideas that are either not baked enough, or things we might want to punt to a future release, or maybe not do at all. | |||
;JS API for setting status | ;JS API for setting status | ||
| Line 91: | Line 86: | ||
On the fence on this one. Not sure it really makes sense, since the browser could initiate requests unrelated to any page. This should likely be solved on the site by using multiple AMCDs with unique URLs telling the site what the method is for (e.g., put path="/connect?ref=foo" in the AMCD). | On the fence on this one. Not sure it really makes sense, since the browser could initiate requests unrelated to any page. This should likely be solved on the site by using multiple AMCDs with unique URLs telling the site what the method is for (e.g., put path="/connect?ref=foo" in the AMCD). | ||
;Splitting authentication profiles from other profiles | |||
We have some thoughts around it, but it's not clear yet. More work to do here. | |||
;Federation | |||
Still distilling proposals here, stay tuned. | |||
;Multi-factor auth, other future ideas | |||
Perhaps we need a way for sites to specify more complex scenarios? Like, choose any two of these auth profiles {...}, or even more compex schemes. | |||
Execute code from the server that determines what to do? (crazy). | |||
Definitely need to explore this idea some more. | |||