Changes

Jump to: navigation, search

CloudServices/Roadmaps/Identity

1,636 bytes removed, 00:20, 3 March 2011
no edit summary
|pagetitle=Mozilla Identity Roadmap
|owner=Dan Mills
|updated=Feb Mar 2011
|status=Draft
|description=Mozilla ID (final name TBD) will be a Mozilla-operated service that provides a safe and simple to use federated ID system for Web developers and users.
Signing into sites is a common pain point on Web sites today, and this service will be one piece of a larger effort to fix that pain. We've made an effort to bring a 'single sign-on'-like experience to the Web, to provide hooks for browser integration, to make sure the system works on current-generation browsers, to give users the ability to choose their ID provider and use their preferred provider on what identity they choose to disclose to any Web site, and to protect user privacy while at the same time facilitating an exchange of profile data with sites.
}}<section end=summary />
* Log retention policy
* Number of transactions/sec to support
 
= UX Mockups =
 
[[File:WebLogin.jpg|200px|thumb|left|Iteration 1]]
 
[[File:Sign-In-Single-Email.png|200px|thumb|left|Iteration 2: Single email]]
 
[[File:Sign-In-and-Site-Identity.png|200px|thumb|left|Iteration 2: Multi email]]
 
<br clear="all"/>
= Releases / Roadmap =
* JS API needs to allow for sites to customize the button they embed
* Need to sketch out what admin API will look like
 
 
== Open Questions ==
 
;M1
 
* Who will create the js api?
** what actions will the js api need to provide?
** how will the library be invoked?
* Where will sign-in page be hosted?
* How will claimed id's be hashed &amp; associations stored?
* Is site customization of the login button compatible with restricting introspection of the inserted page elements?
 
;M2
 
* Will we be accepting Google sign-ins (iow. are we proxying google or are we accepting Google as a OP?)
 
OpenID has no concept of proxying. Sites will be RPs to us, and we will be RP to Google (as well as other OpenID providers).
 
* Is there an api for sync account creation flow?
* Can we create Sync accounts in this way and still allow the Sync UI in the browser to connect to that account? Sync UI currently expects you to either (a) create a new account, or (b) know the details, including the sync key.
* Captcha mechanism to use?
 
Accounts created on our service directly (i.e., not federated OpenID/GoogleID accounts) will be regular accounts like the Sync service makes, and should use the same CAPTCHA service (ReCaptcha at the moment).
 
* Is content disclosure per partner or global?
 
Disclosure is for each RP.
 
** where will this preference be stored?
** Will user be able to modify/revoke access?
 
Yes, the admin API and the dashboard will provide this functionality.
 
;M3
 
* Who will be doing chrome work?
* Where/how will meta data be stored?
* Who will be the PoC for CAS?
* How will user be polled for additional attribute exchange?
* Do we determine signed in state without actively polling remote site (cookies lie)?
= QA =
= Localization =
 
= UX Mockups =
 
[[File:WebLogin.jpg|200px|thumb|left|Iteration 1]]
 
[[File:Sign-In-Single-Email.png|200px|thumb|left|Iteration 2: Single email]]
 
[[File:Sign-In-and-Site-Identity.png|200px|thumb|left|Iteration 2: Multi email]]
 
<br clear="all"/>
= Security & Privacy =
** doesn't provide enough information to RPs (e.g. name, photo, etc.)
** confusing (I'm a URL?)
 
<br clear="all"/>
946
edits

Navigation menu