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 features

Primary API Features in scope [1] 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

When accessing a service, the user and the service provider have a common interest in making sure that the user, the subscription, or the device accessing the service is a genuine one, and that the transaction performed cannot be denied. Authentication is a means to achieve such trust. The following example comes from online streaming video. Netflix would like to implement a fast, lightweight, secure application protocol for communication between a Netflix client implemented in JavaScript, running in a browser or other HTML/CSS/JS-based platform and Netflix servers (running on a cloud computing platform). Authentication may be bootstrapped from some pre-provisioned credential bound to the device. This secure protocol is then used for functions such as authorization to play movies and reporting of usage statistics. See http://www.w3.org/wiki/NetflixWebCryptoUseCase for details.

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

• A pure-JavaScript browser plugin (Greasemonkey, etc.)
• A JavaScript library (technically an entire runtime, so the collection of all JavaScript code) that is signed by a party other than the author, such that non-signed code (cross-site scripting, tampered, corrupted, etc.) could not execute.

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 features

Secondary API Features that may be in scope [1] 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

SSL VPN

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.

• http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html

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.

Imagine if Web mail had a couple more buttons: [Find/Import Public Key], [X] Encrypt Message. Assume that the issue of "trust" is solved elsewhere, I import public keys I trust for my contacts, the web mail publishes the JavaScript source code in an auditable format, and it is audited and considered trusted. I can encrypt emails and attachments for my contacts inside of a Web UI, and when they are received by the web mail operators, they cannot decrypt them.

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

Miscellaneous

• OpenPGP (RFC 4880) compatibility. Not necessarily built in, but a way to build it out of primitives.
• A mechanism for a user agent to see encrypted text, look in your key store (either client certificates or other) for a corresponding private key, decrypt the content automatically (prompting for a password if necessary), but not expose it to the web application via JavaScript.
• Exposing the server certificate (possibly structured, if not we'll need a bullet-proof, signed, X.509 library) and path of the TLS connection as JavaScript objects.
• Exposing the client certificate supplied up through the SSL library and Web server to application code

References

[1] http://www.w3.org/2011/11/webcryptography-charter.html