Confirmed users
471
edits
Identity/CryptoIdeas/03-ID-Attached-Data: Difference between revisions
Jump to navigation
Jump to search
Identity/CryptoIdeas/03-ID-Attached-Data (view source)
Revision as of 01:26, 7 February 2013
, 7 February 2013sketch out jetpack modules
(sketch out jetpack modules) |
|||
| Line 260: | Line 260: | ||
they are the first to use class-C data and thus both responsible for creating | they are the first to use class-C data and thus both responsible for creating | ||
kC (creating incompatible keys). | kC (creating incompatible keys). | ||
== Jetpack Modules == | |||
The first implementation will probably be a cluster of Jetpack modules. The | |||
"browserid" module must, for now, open a visible tab from an | |||
externally-hosted site, which can use include.js to present the BrowserID | |||
signin dialog. Once BrowserID accepts non-http/https schemes for the | |||
audience= field, this can change to opening a visible tab from an | |||
internally-provided resource: URL. Later, the module can use chrome UI for | |||
the dialog, rather than opening and closing a regular browser tab. The API | |||
should remain the same. | |||
The KDF module is where all the protocol work happens. It should probably | |||
have a register-callback method, then a "go" method (just like | |||
navigator.id.watch() and navigator.id.request()). The callback should receive | |||
the data-encryption keys, functions to encrypt/decrypt data with those keys, | |||
and something to access tokens. We need a way to inform the KDF module that | |||
we've successfully communicated with the storage server, and we no longer | |||
need old tokens (so it can discard kA/kB/kC safely). | |||
The application-specific module then talks to whatever internal resource is | |||
being synchronized, and makes HTTPS requests to its storage server. | |||
[[File:PICL-07-jetpack-modules.png|Jetpack Modules]] | |||