BrowserID Key Wrapping: Difference between revisions
(Created page with "When a user logs in to a web site directly, that web site has the user's password available to it, and it can use this password as a source of entropy for a cryptographic key. On...") |
|||
| Line 2: | Line 2: | ||
== API and Overall Behavior == | == API and Overall Behavior == | ||
A web site wants to have access to a securely stored cryptographic key bound to each of its users. That key should survive across multiple BrowserID logins, and be as stable as possible: if it is lost, the user's data that the site chooses to secure with this key will also be lost. | |||
BrowserID does <em>not</em> store any data on behalf of the web site. Instead, it provides a wrapping/unwrapping API. The web site is expected to generate the user's key, wrap it via BrowserID, and store the wrapped key on its own servers. | |||
It goes like this: | |||
// web site logs the user in via BrowserID | |||
navigator.id.get(gotAssertion); | |||
function gotAssertion(assertion) { | |||
// web site generates a key | |||
// wrap the key | |||
navigator.id.secret.wrap(assertion, key, | |||
function(wrappedKey) { | |||
// store the wrappedKey on the server | |||
}, | |||
function(error) {}); | |||
The plaintext key must be base64-encoded. The wrappedKey that is passed back is also base64-encoded. | |||
=== Internal API === | |||
Before this is exposed as a content API, BrowserID exposes secret wrapping as an internal API: | |||
navigator.id.internal.secret.wrap(origin, assertion, plainKey, successCB, failureCB) | |||
navigator.id.internal.secret.unwrap(origin, assertion, wrappedKey, successCB, failureCB); | |||
In this internal API, the <tt>origin</tt> has to be explicitly specified. | |||
== Architecture == | == Architecture == | ||
Revision as of 00:44, 5 January 2012
When a user logs in to a web site directly, that web site has the user's password available to it, and it can use this password as a source of entropy for a cryptographic key. Once a web site uses BrowserID, that goes away. With BrowserID key wrapping, we're bringing this feature back. We're providing a way for web sites to get access to a cryptographic key based on the user's login.
API and Overall Behavior
A web site wants to have access to a securely stored cryptographic key bound to each of its users. That key should survive across multiple BrowserID logins, and be as stable as possible: if it is lost, the user's data that the site chooses to secure with this key will also be lost.
BrowserID does not store any data on behalf of the web site. Instead, it provides a wrapping/unwrapping API. The web site is expected to generate the user's key, wrap it via BrowserID, and store the wrapped key on its own servers.
It goes like this:
// web site logs the user in via BrowserID
navigator.id.get(gotAssertion);
function gotAssertion(assertion) {
// web site generates a key
// wrap the key
navigator.id.secret.wrap(assertion, key,
function(wrappedKey) {
// store the wrappedKey on the server
},
function(error) {});
The plaintext key must be base64-encoded. The wrappedKey that is passed back is also base64-encoded.
Internal API
Before this is exposed as a content API, BrowserID exposes secret wrapping as an internal API:
navigator.id.internal.secret.wrap(origin, assertion, plainKey, successCB, failureCB) navigator.id.internal.secret.unwrap(origin, assertion, wrappedKey, successCB, failureCB);
In this internal API, the origin has to be explicitly specified.