From W3C Web Cryptography Wiki
Use Case Index
This draft originated from the WebCrypto API community group draft http://www.w3.org/community/webcryptoapi/wiki/Use_Cases. For past discussion, please see http://lists.w3.org/Archives/Public/public-identity/2011Dec/0033.html
This draft is an index for the use cases identified. Maintaining SSL servers for all web content is a big burden for IT companies. Web developers can protect only selected content with lightweight secure methods. Most of the following use cases fall in this category. To add a use case to this draft, please add a page and link it from the list below. Some of the use cases enable users to make payments and enable web applications to identify users and devices.
Primary API Features in scope  are: key generation, encryption, decryption, deletion, digital signature generation and verification, hash/message authentication codes, key transport/agreement, strong random number generation, key derivation functions, and key storage and control beyond the lifetime of a single session. In addition, the API should be asynchronous and must prevent or control access to secret key material and other sensitive cryptographic values and settings. Encryption and decryption include both symmetric and asymmetric cryptography.
Client authentication: An Example From a Video Streaming App
Note: This example from Netflix relies on a secret provisioned out of band in a secure element, but one can imagine an application generating and storing its own secret locally and using the secret for each access to the service.
Signed web applications
Protected local storage
An application may want to leave some local data in Web Storage. But this application doesn't want the data to be accessible to everybody on the device. The application may encrypt the data before storing it, to make sure the storage preserves confidentiality.
Remote storage, e.g., browsing configuration in the cloud (N)
A user may want to store in the cloud some information related to his browsing activities (such as bookmarks, history, passwords, certificates, and adds-on). This kind of use case requires data to be stored in the cloud in confidentiality, for example, encrypting the data associated with the user account.
Corporate sensitive information access and exchanges (N)
Companies deploying access to sensitive resources to their employees, such as mail and documents, may need to protect access to their assets with a priori authentication and insure confidentiality.
Peer-to-peer secure messaging
With the development of communication over social media and in general over the web, people are expecting web applications to address some privacy concerns. As a consequence, any tool that would provide confidentiality in peer-to-peer exchanges may help to build this trust.
- Encrypted passages in web applications, distributed a la alt.anonymous.messages (that is, broadcast to all) but readable by only a select few. (Facebook status messages)
- Off-the-record (OTR) messaging in a web messaging platform (gchat, Facebook)
- Secure messaging between browsers (p2p) must be done like WebRTC.
B2C personnal information exchange
When companies or governments send personal information to their customers or citizens via digital exchanges, they may need to secure this exchange with a specific secret, which will allow only the targeted person to be able to actually read the information. As an example, in Korea, many credit card companies and tax agencies send bills to customers via email attachments of encrypted HTML messages, and users can view the bills with their keys.
- iPhone app: http://itunes.apple.com/il/app/inisafe-mail/id447572293?mt=8
- Web based: http://www.flickr.com/photos/dracophotos/2698053010
Secondary API Features that may be in scope  are: control of TLS session login/logout, derivation of keys from TLS sessions, a simplified data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption.
Financial transactions: online banking
Korea would like to replace plug-in based certificate service with JS-based applications running in a browser or an HTML/CSS/JS-based platform between banks and public certificate servers. It may require TLS session login/logout, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption. See http://www.w3.org/wiki/KoreaWebCryptoUseCase for details.
Credit card processing
Most credit card transactions have been based on the card number, expiration date, and CVC code. Recently VISA 3D was developed to protect card transactions with a PIN code. But, in the long term, a user certificate issued by a credit card company is more secure than previous methods. Some Korean credit card companies have already performed certificate-based card transactions.
- ISP Process: http://www.vpay.co.kr/home/eng/02_solution/solut_ecomm_credit.html
- ISP Demo: http://www.vpay.co.kr/home/eng/03_support/support_01_isp_demo.html
Most companies use SSL-based VPN with pre-installed agent programs, but the method of authentication is just a PIN code or one-time password. Certificate-based VPN on the Web will be a good market to many security companies and useful to users.
Handling S/MIME mail
Most Web mail services such as Gmail and Yahoo Mail don't handle S/MIME messages because of a lack of server resources. We can perform email encryption and decryption in Web-based email systems. It's an important problem for secret deals between international companies.
Handling XML encryption
Despite small volumes, there are still SOAP-based XML communications in governments and big companies. This naturally can be migrated to web applications.
Signing data using a smart card
Although these use cases refer to a smart card, they can be generalized to client certificates and private keys that reside on the disk. These use cases were submitted by James L. Davenport in the message titled "Need for Smart Card support".
The user must be prompted for his PIN prior to signing with the smart card. Also, the system must display to the user the data that is being signed, so that he knows what he is signing.
Using smart cards to sign data submitted to internal company web apps:
a. An employee accesses the company web app where he can make changes to his employee benefits (dental, medical, eye). He enters the changes and presses Submit. The changes are signed using the employees' smart card and then sent to the web app which validates the signature and processes the benefits changes.
(Other similar use cases are omitted.)
Using smart cards to sign data submitted to public web apps:
d. An individual accesses his doctor's web app which has a form for authorizing release of medical records to another family member. The individual fills in the form and presses Submit. The form data is signed using the individual's personal smart card and then sent to the web app which validates the signature and releases the medical records to the family member.
(Other similar use cases are omitted.)
Signing an authentication challenge
The browser may sign a challenge from a server for PKI based challenge-response handshake to perform authentication. The signing private key can be stored on a smart card or on the disk.
Decrypt a message using private asymmetric key
Encrypt a message for someone using their pubic asymmetric key
Out of scope
- special handling directly for non-opaque key identification schemes
- access-control mechanisms beyond the enforcement of the same-origin policy
- functions in the API that require smartcard or other device-specific behavior
- OpenPGP (RFC 4880) compatibility. Not necessarily built in, but a way to build it out of primitives.
- Exposing the client certificate supplied up through the SSL library and Web server to application code