Hi Axel et al. Thanx for mentioning my WebPKI.org work :-) I have personally not taken the JS / DOM route because in the case you have a process that needs to be secured beyond a single request/response-pair you tend to run into difficulties combining trusted and untrusted code.
I.e. all my current work-items are similar to HTTPS URLs, where the browser transfer the URL to trusted code browser and the rest is performed from there. I must though confess that I haven't done an extensive research if for example end-to-end secured provisioning (which is the by far the most complex project in the collection), actually is feasible by exposing a bunch of JS APIs. I did the *assumption* that it isn't :-| Microsoft will replace their "APIish" CertEnroll scheme something "protocolish" based on WS. In addition to running in trusted layers you also get XML validation. My next step is creating an engine for such schemes so that it becomes easier creating XML browser protocols. However, David Dahl's DomCrypto looks cool so please don't be put-off by my non-JS ideas! Cheers, Anders On 2011-04-27 18:09, axel.nenn...@telekom.de wrote: > > Hi Hannes, > > A) Authentication Mechanisms > Anders Rundgren is a caller in the desert for this for years: > http://webpki.org/ > B) Authorization Interface > I think this is the point closest to oauth and that needs the most work. > C) Standardized JavaScript Crypto Library Support > This was discussed e.g. in the NSS group for years > https://www.mozilla.org/projects/security/pki/nss/ > If I recollect the most common argument right it was: > "Developers will implement bad security if we give them the basic crypto > building blocks. Combining good crypto A with good crypto B will likely > yield bad crypto C" > D) Moving Crypto Into the Browser > Same comment as for item C. I think your paper should be more specific > to oauth's needs and propose what is needed for oauth and the > (preferrably) ONE way to use the parts. > http://daviddahl.blogspot.com/2011/03/in-which-author-explains-domcrypt- > in.html > > I know of one javascript implementation of signed json web tokens in > Firefox. But I think that crypto in javascript is not secure (enough? > Besides speed). > > -Axel > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: Wednesday, April 27, 2011 5:06 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Paper for the W3C Identity in the Browser >> Workshop aboutOAuth >> >> Hi guys, >> >> Barry, Blaine and I compiled a short position paper for the >> upcoming W3C identity in the browser workshop. >> Here is the call for participation: >> http://www.tschofenig.priv.at/svn/w3c-browser-identity/ >> >> Here is the position paper: >> http://www.tschofenig.priv.at/svn/w3c-browser-identity/oauth.pdf >> >> Let us know if you have some comments. We are happy to >> incorporate them. The submission deadline is unfortunately >> today. This is yet another one of these last minute things, I know. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
