668
edits
BrowserID Key Wrapping: Difference between revisions
→API and Overall Behavior
| Line 22: | Line 22: | ||
The key must be base64-encoded. The wrappedKey that is passed back is also base64-encoded. The plaintext is expected to be fairly short: mostly this is for wrapping other keys. | The key must be base64-encoded. The wrappedKey that is passed back is also base64-encoded. The plaintext is expected to be fairly short: mostly this is for wrapping other keys. | ||
=== Content API === | |||
navigator.id.secret.wrap(assertion, plainKey, successCB, failureCB) | |||
navigator.id.secret.unwrap(assertion, wrappedKey, successCB, failureCB); | |||
We use the XHR approach, with one callback for success and one for failure. | |||
The audience of the assertion must match the origin of the content, and a wrapped key can only be unwrapped by the same origin that wrapped it. | |||
=== Internal API === | === Internal API === | ||
| Line 27: | Line 36: | ||
Before this is exposed as a content API, BrowserID exposes secret wrapping as an internal API: | Before this is exposed as a content API, BrowserID exposes secret wrapping as an internal API: | ||
In this internal API, the <tt>origin</tt> has to be explicitly specified. | In this internal API, the <tt>origin</tt> has to be explicitly specified. | ||