Warning:
This wiki has been archived and is now read-only.
Use Cases
Contents
Use Case Index
This draft was moved to http://www.w3.org/2012/webcrypto/wiki/Use_Cases
This is a draft index for the Use cases identified. Maintaining SSL servers for all of web contents are very big burden for IT companies. Web developers can treat only selected contents with light secured methods. Most of as followings are included in this cases. To add a use case in this section, please add a page and link it from the list below. Some of cases can make payments by users and determine users and devices by web applications.
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 authentifications
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 also in http://www.w3.org/wiki/NetflixWebCryptoUseCase
Encrypted 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 (possibly me), such that non-signed code (xss, tampered, corrupted, etc) could not execute.
Storing local storage
App A wants to leave some local data in Web Storage or whatever it's called. But it doesn't want this to be accessible to everybody on the machine. It'd like it to be encrypted using a private key that needs a passphrase.
Secure messaging
- Encrypted passages in web applications, distributed ala alt.anonymous.messages (that is, broadcast to all) but readable by only a select few. (Facebook status messages)
- OTR in a web messaging platform (gchat, facebook)
- Secure messaging between browsers (p2p) must be done as like WebRTC.
Encrypted bill
In case of a bill of credit card or telephone or personal medical data from hospital, the encrypted messages can be secure because anyone cannot see that. In Korea, many credit card companies and tax agencies send bills to customers via email attachement encrypted HTML messages and user can see it by their key.
- 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 Transaction: Online bank
Korea like to implement to replace plug-in based certificate service to JS based applications running in a browser or other HTML/CSS/JS-based platform between banking and public certificate servers. It may be included 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 also in http://www.w3.org/wiki/KoreaWebCryptoUseCase
Credit card process
Most of credit card transaction has been based on card number, expire date and CVC code. Recently VISA3D was developed similar with pin code. But, permantly, user certificate issued by credit card is more secure than previous methods. Some Korean credit card companies have already used certificate based card transations.
- 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 of company used SSL based VPN with pre-installed agent program, but the method of authentification is just pin code or one-time pasword. Certificate based VPN in web will be good market to many security companies and useful to users.
Handling S/MIME mail
Most of web mail services as like Gmail, Yahoo Mail don't handles S/MIME messages because of lacks of server resources. We can process email encryption and decryption in web based email system. It's very important problem for company based secret deals between internatioanl companies.
Imagine if web mail had a couple more buttons: [Find/Import Public Key], [X] Encrypt Message. Assume the issue of "Trust" is solved elsewhere and I import public keys I trust for my contacts, and assume the web mail publishes the javascript source in an auditable format, and it is audited and considered trusted. I can encrypt emails and attachments to my contacts inside of a Web UI, and when they are received by the web mail operated, they cannot decrypt them.
Handling XML Encryption
Despite of small cases, there are still SOAP based XML communications in govenments and big companies. This naturally can be migrated to web applications.
Out of Scope
- Smartcard based Authentification
- Hardware Crypto Token
Etc
- OpenPGP (RFC 4880) compatibility. Not necessarily built it, but a way to build it out of primitives.
- A mechanism for a User Agent to see encrypted text, look in your keystore (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 bulletproof, signed, X509 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