RE: JS crypto?

Hi Nathan,

This seems to be the current related standardization effort:
http://bondidev.omtp.org/1.5/crypto.html
=
http://bondi01.obe.access-company.com/1_5_5602_145/crypto.html

Past related efforts were less robust (just signText in WMLScript) in http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-161-wmlsscriptcrypto-20010620-a.pdf

Thanks,
Marcin


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Nathan
Sent: Wednesday, May 12, 2010 6:31 PM
To: Jeremy Orlow
Cc: public-webapps; art.barstow@nokia.com; foaf-protocols
Subject: Re: JS crypto?

Arthur:
Thanks for pointing me in the right direction [1] :)

Jeremy:
Fully agree re the right time to explore the possibility.

I can think of many, many use cases - particularly in conjunction with
work that's going on in the social, swxg, foaf, foaf-protocols, linked
data, and read write web camps.

With foaf+ssl we have public keys in profiles used for authentication
over HTTPS where the user has a certificate installed in the browser,
since the public key is available it leads the way to encrypted
communication over http between two parties, and also mounting
information on the web which is encypted with those public keys, making
it safe and secure - obviously if one where to pass the private key in
to a server side application then security would be somewhat flawed,
however if it's in the browser then this paves the way for almost
infinite uses - including many web of trust related functions
(particularly with signing resources exposed by uris).

So whilst usage may be somewhat low, I fully envision need and usage
rising exponentially over the next few years and onwards, so a
relatively early start at standardisation would indeed be a very good thing!

[1] http://lists.w3.org/Archives/Public/public-web-security/

Best,

Nathan


Jeremy Orlow wrote:
> This came up not too long ago in the context of persistent storage.  The
> verdict (IIRC) was that we're not interested in adding crypto just to
> the persistent storage APIs, but that we might be interested in adding a
> general crypto API.
>
> Does anyone have any data for how widely used window.crypto and/or JS
> library alternatives are?  If they aren't widely used, maybe it's worth
> seeing if we can find use cases for crypto in the browser that aren't
> satisfied by JS libraries?
>
> To answer your question, I'm not aware of any existing standardization
> efforts, but I think the time might be right to explore the possibility.
>
> J
>
>
> On Wed, May 12, 2010 at 5:09 PM, Nathan <nathan@webr3.org> wrote:
>
>> Hi All,
>>
>> Unsure if this is the best place to ask, but is there currently any JS (or
>> user agent) support for cryto functions such as sign/seal/encrypt/decrypt?
>>
>> Perhaps a working group, a draft, anything?
>>
>> I would be very keen to see crypto support in all the browsers standardized
>> and methods exposed to JS.
>>
>> For instance, if you have your public key on the web somewhere, I should be
>> able to seal a document using it, publish it on the web, and know that if
>> you visit that uri in your browser that it will decrypt it using the private
>> key from a certificate you have installed in the browser.
>>
>> Best & thanks in advance for any response,
>>
>> ps: aware of window.crypto in firefox/gecko
>>
>> Nathan
>>
>>
>



________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Kiyoyasu Oishi, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 12 May 2010 16:55:23 UTC