.

TimestampWhat methods of the Crypto API are you most interested in?In your planned usage, who are the users of this API?What data is being processed/encrypted/signed, etc?Why is this data being processed/encrypted/signed, etc?Why are you interested in a Web Crypto API? Are you interested in a high-level, idiot-proof API or a low-level API?What industry or organization are you involved with?

.

5/21/2012 10:32:37Public Key Encryption, Symmetric EncryptionApplication like webex are interested in making sure that data can be encrypted from one end users browser to the other ends users browser without the web servers in the middle (like webex) having access to the data.
Small text messages such as IM style chat. Larger chunks of data that represent documents such as as slides.
The webex application is trying to help two users Alice and Bob, collaborate, but Alice and Bob do not want to share the information with webex. The goal is not to stop webex from attacking Alice and Bob but to allow Alice and Bob to verify a promise that webex did not do this. It is more about detection than stopping it from happening.

You can imagine a solution where webex helps distribute public keys, and users can check those out of bound if desired.
a standard, cross-browser API, the speed of native crypto implementation, persistent key storageLow-level

.

5/21/2012 11:45:33MAC, Public Key Encryption, Symmetric EncryptionNon-Crypto Web App Developers User Entered Data intended to be hidden from the serverIn an Honest but Coercible or Honest but Curious threat model, the server will store users data, but should not be able to read it.

This could be encrypted files, encrypted documents in a Google Docs-style app, or PKI-encrypted status updates in a Facebook-style application.
a standard, cross-browser API, the security of isolating the keys from JavaScript code, persistent key storage, access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayHigh-level, idiot-proof

.

5/21/2012 13:12:05SignatureFinancial transactions such as banking, cyber trading and credit card processingdata in web applications for financial transactions for validations of these dataa standard, cross-browser API, persistent key storageHigh-level, idiot-proof

.

5/21/2012 14:02:58Signature, MAC, Public Key Encryption, Symmetric Encryption, HashDevelopers (experienced)Signed, encrypted - Commercial documents
Encrypted - Local data from HTML5 applications and other files
Proof of signature
Proof of transaction
Confidentiality in case of loss of device
a standard, cross-browser API, access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayLow-level

.

5/21/2012 15:08:32Signature, MAC, Public Key Encryption, Symmetric Encryption, HashPrimarily web application developersAuthentication data (to verify user or device)
Digital media content that needs to be decrypted
Application data that needs to be signed
User and device authentication
Content protection
a standard, cross-browser API, persistent key storage, access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayLow-level

.

5/21/2012 15:24:30Symmetric EncryptionCable Television Interactive Application DevelopersAudio/Video/Application dataTo protect high-value content and servicesa standard, cross-browser APILow-level

.

5/21/2012 17:02:21MAC, Symmetric Encryption, "hidden" key exchangeNetflix security software engineers porting / creating our own RESTful protocol security to generic web browsers and beyond.Arbitrary device <-> server protocols. At present the data includes: device authentication data, user authentication data, device registration data, digital content authorization data, content metadata, key exchange (Diffie-Hellman) data, and much more.Data is encrypted to maintain privacy. Data is MAC'd (or signed in some cases) to provide authentication and integrity protection.a standard, cross-browser API, the security of isolating the keys from JavaScript code, persistent key storage, access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayLow-level

.

5/22/2012 6:15:34Signature, HashDigital certificate Authorities producing standard national PKI credentials the user´s public key for certificate enrollment, the download of digital certificate and publication on browser repository, and data to be deciphered/ciphered or hashed and signed.the key pairs for digital certificate signature by the CA and most important any type of form rendered by the browser signed by user´s private key and deciphered/ciphered by security or privacy reasonsa standard, cross-browser API, access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayLow-level

.

5/22/2012 6:19:50Signature, MAC, Public Key Encryption, Symmetric Encryption, HashRelated to the the high level/love question: I think it should be both ways.

Both advanced users and "idiot" users should be able to use this api.
Everything from authentication schemes, to videos/sound.We should not put any restrictions here.a standard, cross-browser API, the speed of native crypto implementation, The security of using a common well defined APIHigh-level, idiot-proof

.

5/24/2012 14:37:31Signature, MAC, Public Key Encryption, Symmetric Encryption, HashApplication developers wanting to easily deploy crypto in their applications.As much as possible, hopefully.Because it's a good idea.a standard, cross-browser APIBoth. Power users obviously need low-level APIs to consume custom (read: already existing) services. However, there is a lot that could go wrong in implementations if only low-level APIs are provided. A high-level API for common tasks (like symmetric encryption) I consider to be a must-have. People are going to implement this anyway. So, you might as well provide a "batteries included" solution that covers the 95% and that people can rally behind as a standard way of doing things. By providing a high-level, idiot-proof API, you also encourage adoption of better security, which moves the web forward, IMO.Browser Maker

.

5/29/2012 18:34:55Signature, MAC, Public Key Encryption, Symmetric Encryption, HashJavaScript crypto library developersJSON representations of identity claims (JSON Web Tokens - JWTs)Integrity, Non-Repudiation, Confidentialitythe speed of native crypto implementationA sufficiently low level API to implement the IETF JSON Object Signing and Encryption (JOSE) specificationsStandards Architect

.

5/30/2012 9:43:49Signature, MAC, Public Key Encryption, Symmetric Encryption, HashApplication developersThat depends on the application. For example, banking or online shopping application may want to encrypt the transaction and sign the transaction if it involves a large amount; government application, e.g. tax returns, will require both encryption and signature; health care applications would need encryption to protect users' privacy.Confidentiality, integrity, privacy protection, non-repudiationaccess to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayBoth high-level and low-level. May be we should have two APIs?Security company

.

5/30/2012 14:01:39Signature, MAC, Public Key Encryption, Symmetric Encryption, HashOne use case can be the security critical applications for online authentication or online transactions that rely on the presense of a secure element, e.g. a smart card connected to a user's computer. The applications should be able to use keys stored in such a secure element. One option could be to extract the keys from the secure element and use it inside the browser (e.g. for bulk encryption using symmetric keys) without exposing the key to the JavaScript code. Another option could be to do crypto processing inside the secure element so that keys do not leave the secure element (e.g. asking a smart card to sign a hash).The data being processed can be the following:
1. Sign a document hash
2. Sign a challange from a server for PKI based challenge-response handshake to perform authentication.
3. Decrypt a message using private asymmetric key.
4. Encrypt a message for someone using their pubic asymmetric key.
5. Perform hash of a large document
6. Bulk encryption of a large document using a symmetric key.
7. Bulk decryption of a large document using a symmetric key.
The reason of each of these 7 operations listed above is as follows:
1. signature done for non-repudiation; if you sign a document (hash) with a key that is on your smart card, you cannot later repudiate the signature.
2. By signing a challange from the server, you prove that you own the smart card, and thus prove who you are. Secure tokens such as smart cards are bound to a one person only. This provides a strong two-factor authentication on the Internet.
3. Message sent to you by others are encrypted using your public key, you and only you can decrypt it using your private key. If this key is stored on the smart card, you can be sure no once else will be able to see the message sent to you.
4. By signing a message with someones public key, you ensure that only those who have access to private key can see the message. The public keys need not be stored in hte secure element.
5. It is important to be able to perform hash of a large document quickly. Hashing is needed both during signing and signature verification. What is signed is a hash and not the actual data - which may be too big to sign.
6. Encryption of document can be important when data is stored in the cloud. Instead of sending the data in the clear and then relying on the cloud storage provider to encrypt it, some applications may want to perform client-side encryption and encrypt the data before sending to server.
7. This is the other side of coin for use case 6. When data is fetch from the server, it is encrypted. Before use, it is decrypted using the bulk decryption API on the client. The symmetric keys for both encyption and decryption can be stored in a secure element.
persistent key storageI feel that the API should be low level to allow applications to develop their own application logic. What is important is to be able to define the storage containers for cryptographic keys. The applications can then decide how and where the keys should persist and how they can be made available for use. We need not support all algorithms, but only the most commonly used ones - even if they are considered weak by some.Device Maker, Application Developer, smart card and digital security

.

5/30/2012 16:49:32Signature, Public Key Encryption, Symmetric EncryptionWeb browser users who store encrypted data in the cloud.Bookmarks, browsing history, passwords, configuration data, addons - basically any browser profile data.The data is being encrypted locally in order to keep it completely private to the user.a standard, cross-browser APILow-level API that allows some interoperability with existing standards, however that is not a main focus. Browser Maker

.

5/30/2012 17:03:57MAC, Public Key Encryption, Symmetric Encryption, authenticated encryptionclient-side encryption and MACing of data to be stored on a server. key derived (client-side) from a password
text notes and small personal information fieldsto reduce the severity of the server compromisea standard, cross-browser APIhigh level. fully secure by default Internet Service, Browser Maker, Open Source Developer

.

5/30/2012 17:16:50Public Key EncryptionEveryone I want to share something with, and only they.Textual mostly.Privacy.access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayHigh-level.Browser Maker

.

5/30/2012 17:42:32Public Key Encryption, Symmetric EncryptionEveryone.Everything.To benefit the user.a standard, cross-browser APILow level. The API should provide the necessary building blocks to build things that can't be built with a high-level API. A high-level idiot-proof API should be supplied by JS libraries.Browser Maker, Application Developer, Open Source Developer

.

5/30/2012 18:13:21Signature, Public Key EncryptionA crypto messaging client which would otherwise need to create its own (privileged) API to access platform crypto primitives which would likely not be cross-browser.E-mails or instant messages.User privacy. The mail server does not have an inherent need to read the user's messages unless the user desires full-text search from the server, for example.the speed of native crypto implementationHigh-level for existing (or new) standards. Specifically, easy/safe PGP-support would be important for now. The ability to support new protocols like multi-party off-the-record messaging (if further specified) would be great.Browser Maker, Application Developer

.

5/31/2012 8:53:55Signature, MAC, Symmetric EncryptionAuthentication and secure local storage.Mostly internal corporate dataProvide protections for data at rest and stronger authentication mechanisms.the speed of native crypto implementationLow level, however I can see it being abused by those who do not grasp cryptography, neither is a high level a perfect choice and forgoing the implementation of broken crypto eg. MD5/SHA1, RC4 is one hard to get correct. Default modes of operation are problematic too, I'd prefer a low level, however I'd prefer knowing that the majority of developers can use a high level apiAcademia/Researcher, Internet Service

.

5/31/2012 9:05:22Signature, MAC, Public Key Encryption, Symmetric Encryption, HashUnpacking encrypted data (RSASSA-PSS, RSAES-OAEP, AES256) and hashing/HMAC (SHA256) from typed JavaScript arrays delivered via WebSockets.JSON-encoded data, file blobs.Cloud storage/event network with client-side encryption (Mozilla Sync-style).the speed of native crypto implementationLow-level seems better... high-level can always be provided on top of that.Open Source Developer

.

5/31/2012 12:40:22Public Key EncryptionWeb mail

Instant messaging
ConfidentialityTo have the application maintain no knowledge of the data processedaccess to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayI would like a copy of browser supported PGP primitives with secure key storageApplication Developer

.

5/31/2012 14:16:21MAC, Public Key Encryption, Symmetric Encryption, Hash, RNGCryptocat users: https://crypto.catInstant messaging data as well as file attachments encoded as Data URIs.To provide user confidentiality against both the service's servers as well as third parties/governments.a standard, cross-browser APILow-level. I'm a developer and I'd like the opportunity to code things with more freedom of specification.Academia/Researcher, Application Developer, Open Source Developer, Cryptocat

.

5/31/2012 14:22:13Signature, Public Key Encryption, Symmetric Encryption, Hashnormal human users who have lacked access to tools only currently available to Linux geeks. Also, Syrians.local notes, message board, chat, JS code & general resource signingfedsa standard, cross-browser APIhigh levelOpen Source Developer

.

5/31/2012 14:36:15Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, ECCAverage users who don't know about security or cryptography and need to be protected because of this.Personal/sensitive data.For secure exchanging.the security of isolating the keys from JavaScript codeidiot-proof API.Academia/Researcher, Device Maker, Application Developer, Open Source Developer

.

5/31/2012 15:20:38Public Key Encryption, Symmetric Encryptionfirmsemails, documents-the security of isolating the keys from JavaScript code-Device Maker, Application Developer, Open Source Developer

.

5/31/2012 15:31:16Signature, Public Key Encryption, Symmetric EncryptionPeople who aren't developers, who are looking for something simple.

This would either be SMS or private/direct messaging as an alternative to email.
Simple text messages.To help thwart man-in-the-middle attacks.a standard, cross-browser APILow-level, for easier implementation.Academia/Researcher

.

5/31/2012 15:53:12Signature, MAC, Public Key Encryption, Symmetric Encryption, Hashopen source usersTransactions, passwords...Because they're to sensitive to be exposed on the server side....persistent key storageHigh-levelOpen Source Developer

.

5/31/2012 18:08:40Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, full OpenPGP supportAny JavaScript user; security researchers.Any messages: credentials, peer-to-peer messages (IM), broadcast messages (Twitter), financial transactions, downloads, whatever.Privacy is paramount.a standard, cross-browser APIBoth. It needs to be difficult to make mistakes, but possible for crypto researchers to test and deploy novel ciphers, padding schemes, &c.Academia/Researcher, Application Developer, Open Source Developer

.

5/31/2012 18:16:05Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, Bignums and prime-field / EC multiply opsJS code operated by human beings. Not sure what you mean here.Many small messages.Servers are not trusted with content.the speed of native crypto implementationBoth. High level is fine if it covers enough cases (keygen, just sign, just encrypt, authenticated-encrypt, DH negotiation in useful fields.) Backward compatibility with other cryptosystems not important.Browser Maker, Open Source Developer

.

5/31/2012 19:14:40Signature, MAC, Public Key Encryption, Symmetric Encryption, HashDevelopers familiar with other cryptographic APIs but not cryptographic developers.tickets, certificate requests, serialized session data.integrity, confidentialitythe security of isolating the keys from JavaScript codeMiddle, I fear a low high level api would preclude the message formats needed for interoperability and a low level API would encourage people to shoot themselves.
Internet Service, Certificate Authority

.

6/1/2012 13:06:12PRNGweb developerspasswords and credit cardsn/aa standard, cross-browser APIhigh-level. please don't provide a low-level API unless you want people to use it incorrectlyInternet Service, Browser Maker, Application Developer

.

6/1/2012 15:10:17Pluggable frameworks, Kerberos, ZKPPs, ...See above.See above.See above.I think Web Crypto APIs are mostly -but not entirely- a disaster to be.I think a box/unbox API could be useful as a way of keeping some user information on the user's devices instead of on the servers. For example, instead of storing credit card numbers online the server might store them on the client side encrypted in a [per-user/device!] server key. To recover the client-side user information the server might run a script on the user agent that unboxes the user information with the server key, then it can send the user information for ephemeral usage purposes on the server side, where it will then be deleted ASAP. This is clearly safer than storing the user data in the clear on the server, and safer too than storing it on the server encrypted in a key derived from the user's password.

However, that's as far web crypto goes -- I can't think of any other use cases for which a web crypto API is an appropriate solution or for which there isn't a better alternative.
Application Developer, Open Source Developer, Financial.

.

6/3/2012 14:56:53Signature, MAC, Public Key Encryption, Symmetric Encryption, HashOur developers and potentially our customers- Document signing
- Encrypted local HTML5 data stores
- Encrypted local HTML5 apps
- Confidentiality of information
- Access security
access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayLow-level with access to hardware key stores/encryption enginesDevice Maker

.

6/4/2012 1:39:30Signature, MAC, Public Key Encryption, Symmetric Encryption, HashWe foresee a wide range of use cases, but two specific examples are worth pointing out.

One example is the case where a user has been issued a key through some out-0f-band method and must use this for authenticating requests (and perhaps encrypting them) to a remote service. This is the pattern used, for instance, in various AWS REST APIs, which require HMAC with the user's key.

The other example is the case where a user has been issued a hardware token by some out-of-band process, and must use the cryptographic keys on this token to authenticate (and possibly encrypt) transactions with a remote service. This pattern is followed, for example, with government-issued eIDs in some countries, and with bank-issued security tokens as well. Note that the transactions in this case might include enrollment for a secondary credential such as an X.509 certificate.
See previous answer. In the examples quoted above, the data being processed is related to a request in a client-server protocol. We believe that in many cases, applications will simply use integrity primitives (HMAC or signing) and rely on the underlying TLS/SSL for confidentiality, but there will be cases where encryption is also needed.In our first example, the objective of the cryptographic usage is to provide client user authentication in a situation where the underlying TLS/SSL transport (if present) is being used solely for server authentication.

In our second example, the objective of the cryptographic usage is to provide the server some assurance that the transaction is genuine (e.g. approved by the user using some two-factor authentication) even in cases where the server does not necessarily believe that the client terminal is trustworthy.
a standard, cross-browser APIWhile a high-level API is nice to have, we believe a low-level API is essential due to the diverse needs of applications, and therefore should be the first priority.Browser Maker, Application Developer

.

6/4/2012 2:24:50Signature, Public Key Encryption3rd party developers accessing our UICC/SIM
mobile wallet
payment, loyalty cards, vouchers, tickets, building accesspayment: proof credit
loyalty cards: ...
vouchers: proof it is my voucher, used only once
ticket: use only once or a period of time
building access: proof right to access building/car/service
persistent key storagelow-levelInternet Service

.

6/4/2012 4:40:43MAC, Public Key EncryptionEnd-user who connect with our devicesMedia dataSecurity in the first hopaccess to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayHigh levelDevice Maker

.

6/4/2012 19:46:28SignatureMainly this API will be used in fields of the internet banking and the online securities in Korea.
Mainly money transaction data.Non-repudiation in a money transaction.a standard, cross-browser APIWe want to use a low-level API for signing. Government

.

6/7/2012 15:31:25Signature, Public Key Encryption, Symmetric Encryption, Hashemployeespersonal, human resources type of datasensitivity of the data and authorization/accountabilityaccess to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todaylow-levelGovernment

.

6/15/2012 12:19:43Signature, Public Key EncryptionInternet sealed bidding service. We have been providing this to US state transportation agencies since 1998, but only via a native client application, and more recently, an ActiveX browser extension. We would very much like to put this in the web browser.Sealed bids for performing highway and bridge construction and recently, other kinds of projects.It must remain sealed until the public bid opening. We accomplish this by having the holder of the decryption key be a separate party from the bid deposit service. Also, strong digital signatures are required for legal reasons.access to system cert/key store (e.g., Mac OS X Keychain) or smart cards, or other system or browser resources not accessible to JavaScript todayHigh-level. I see some value in low-level, but think it should probably be a separate API. Application users need a simple, idiot proof way to encrypt, decrypt, sign, and verify.Government, Application Developer

.

7/16/2012 11:27:27Signature, Public Key Encryption, HashDevelopers which will use this API could develop signing applications, avoiding MSCapi and Java.From a simple XML to a complex PDF, including PAdES, XAdES-XL and a simple PKCS#7 Enveloping.Becaus document signing is a required step for a REAL e-admin of XXI century. Current alternatives are at last reduced to JAVA.a standard, cross-browser APIIMHO, a middle option would be great;

signInit() //specify sign algorithm and return certificate to be used
signAdd() //one call for each item to sign
...
signFinal() //do the sign
Academia/Researcher, Government, Application Developer

.

10/15/2012 8:44:09Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, eliptical curves, diffie hellmanDevelopers of web applicaitons. Please see https://github.com/jas-/crypto.js. I have been following the w3c crypto api rfc in anticipation have begun development on a simple interface for native crypto implementations.XMLHttpRequests for authentication, form submissions etc.Security in the event of SSL/TLS cipher downgrades, session renegotiation and other unknowns the speed of native crypto implementationLow levelAcademia/Researcher