Changes

Jump to: navigation, search

Privacy/Features/DOMCryptAPISpec/Latest

357 bytes added, 17:31, 14 October 2011
m
Possible Additions
* All the inputs and outputs should be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful
== Possible Additions == One possible addition we might consider is providing the web site with a secure mechanism having the user confirm a transaction. For example, a bank web site might wish to have the user sign a statement authorizing the transfer of funds from one account to another. Unlike the DOMCrypt APIs described above, this API involves interacting with the user to achieve non-repudiation:
One possible addition we might consider is providing the web site with a secure mechanism having the user confirm a transaction. For example, a bank web site might wish to have the user sign a statement authorizing the transfer of funds from one account to another. Unlike the DOMCrypt APIs described above, this API involves interacting with the user to achieve non-repudiation:
<pre class="brush:js;toolbar:false;">
[Supplemental]
void signWithUserConfirmation(in ArrayBuffer keyID, in DOMString description, in ArrayBuffer data, in PKSignCallback callback);
};
</pre>The signWithUserConfirmation method causes the user agent to display some user interface element containing the human-readable description. If the user confirms the description, the user agent with sign both the human-readable description and the binary data with the key designated by the keyId and supply the signature to the caller via the callback. There are still many details to work out, such as the format of the signed message, but this description is a starting point for discussion.  to deploy this feature to production level, we have to consider following issues.
The signWithUserConfirmation method causes the user agent to display some user interface element containing *is passphase of private key safely entered?. means the humanconfirmation screen need anti-readable descriptionkeylogger mechanism. If *is browser sandbox safe? even on the user confirms the description, the user agent with sign both the humanenvironment is compromized. (virus-infected?) *co-readable description and the binary data operatable with the key designated by the keyId and supply the signature to the caller via the callback. There are still many details to work out, such as the format requirements of the signed messagesecurity compliances (PCI, but this description is a starting point for discussionISO27001...)
== References ==
1
edit

Navigation menu