- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 18 Feb 2011 18:00:38 +0100
- To: Peter Saint-Andre <stpeter@stpeter.im>
- Cc: Peter Williams <home_pw@msn.com>, "nathan@webr3.org" <nathan@webr3.org>, WebID Incubator Group WG <public-xg-webid@w3.org>
On 18 Feb 2011, at 17:32, Peter Saint-Andre wrote: > On 2/18/11 9:29 AM, Henry Story wrote: > >> For me it's easier to put all documents behind https, have users >> publish the public key as specified below for WebID authentication >> and do access control: only allow authorised users to retrieve the >> document. There you get on the fly encryption of any content you >> send. > > To clarify requirements, many of those who are interested in this work > at the IETF want to make it possible for browser-based clients to do > things like encrypted instant messaging or voice and video signalling. Though there again, I suppose the browser could just connect to the server over https and send the content that way... That should be able to cover a lot of use cases. I suppose one could also use DTLS for voice over ip. > So perhaps the scope is a bit broader than WebID different use cases probably... It is just interesting to see how far one can push those down to the TLS level. Every time one can do that one reduces the need for a special encryption and authentication syntax for the content sent. The end user can just receive the content and parse it cleanly. > (I confess to not having followed WebID closely). In the current context one could think of WebID as just being https that works. A client can connect securely and identify himself to any server. The rest is then taken care of by TLS. But signatures and encryption at the document level comes up all the time. Btw. in the semweb land there is the work on "Signing RDF Graphs" by Jeremy Caroll http://www.hpl.hp.com/techreports/2003/HPL-2003-142.html Henry > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > Social Web Architect http://bblfish.net/
Received on Friday, 18 February 2011 17:01:16 UTC