Confirmed users
471
edits
Identity/AttachedServices/Architecture: Difference between revisions
Jump to navigation
Jump to search
Identity/AttachedServices/Architecture (view source)
Revision as of 19:18, 4 June 2013
, 4 June 2013more current-design details
(more current-design details) |
|||
| Line 15: | Line 15: | ||
[[File:PICL-archmap.png|Architecture Map]] | [[File:PICL-archmap.png|Architecture Map]] | ||
This document describes our current plans for these five areas. The https://id.etherpad.mozilla.org/picl-backend etherpad page contains links to other design documents. | |||
== Data Security == | == Data Security == | ||
| Line 35: | Line 27: | ||
We do not yet know which data will be assigned to which category by default, but it is likely that saved-passwords will go into class-B, and many other datatypes will default to class-A. There will be an option to put all data into Class-B. | We do not yet know which data will be assigned to which category by default, but it is likely that saved-passwords will go into class-B, and many other datatypes will default to class-A. There will be an option to put all data into Class-B. | ||
== | == Sign-Up / Sign-In == | ||
Attaching a profile to an account is called "Sign In To The Browser". The UI for this is still under discussion, but will involve the user typing an email address and a password into chrome browser UI (for both new-account creation and signing into an existing account, as well as password reset). This password will be stretched on the client side (using techniques from [[Identity/CryptoIdeas/01-PBKDF-scrypt]]) and used to generate an "SRP password" and a wrapping key (using techniques from [[Identity/CryptoIdeas/02-Recoverable-Keywrapping]]). | |||
The SRP Password is then used in a protocol ([https://id.etherpad.mozilla.org/picl-idp-protocol under development]) to speak with the Key Server . [http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol SRP] is an interactive "zero-knowledge" protocol which gives the participants exactly one chance to show that they agree on a password. The outcome of SRP is a random session key: if the password was correct, both sides will wind up with the same key (otherwise their keys will be different). This session key is used to protect and authenticate some additional messages, which are used to retrieve the class-A and class-B master data-encryption keys, and a "certificate renewal token". This token allows the browser to obtain a signed certificate for a special "PICL Account" identifier (e.g. GUID@picl.persona.org). These certificates will be used for Persona/BrowserID authentication to the storage servers (described [[#Storage_Server_Authorization|below]]). | |||
The class-B master key is encrypted by a derivative of the stretched user password. The master keys are then used to derive per-datatype encryption keys. We use different keys for each datatype so that in the future, we can share e.g. bookmarks with a third party (by telling them the decryption key) without also sharing e.g. stored-passwords. | |||
The KeyServer/PiCL-IdP is a small server which holds a few values for each user: email, SRP verifier, and kA/wrapped(kB). This server also keeps track of which devices have been attached to the account (to help the user with device management and revocation). | |||
If the user forgets their password, they can reset the account (and establish a new password) by providing a Persona assertion for their account's email address. The class-B data is deleted, but the class-A data is retained. | |||
== Conversion / Data Adapters == | |||
== Synchronization == | |||
== Storage Server Authorization == | |||
== Storage Server Format == | |||
== (OLD) Authentication == | |||
Authentication to PICL Services is done via Persona. This means that a browser needs to be natively logged into Persona, so that it can generate the Persona assertions it needs to connect to individual services without user intervention every time the browser reconnects to an existing service. Specifically, if a PICL service runs at https://bookmarks.example.com, the browser gets an assertion for that audience, without prompting the user every time it needs one. | |||
The flow for logging into the browser is more user-agent centric than the typica Persona signin-to-web flow. Redirecting to an IdP is too jarring. Thus, even if we allow different IdPs, the login UI must be consistent and feel like it's part of the browser. | |||
These requirements (and the next Data Security section) call for a design where the browser locally captures the user's email and password, then engages in a protocol with the IdP – persona.org or otherwise – to obtain a certificate. One way to implement this immediately is to embed the invisible persona.org communication IFRAME and call into its internal API, which we recently augmented to include login() and accountExists() calls to support this implementation path. | |||
[[Image:Iframe-login-embedding.png]] | |||