- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 23 Nov 2011 15:50:28 +0100
- To: Mo McRoberts <mo.mcroberts@bbc.co.uk>
- Cc: Peter Williams <home_pw@msn.com>, public-xg-webid@w3.org
On 23 Nov 2011, at 15:42, Mo McRoberts wrote: >> >> if the link point to the same site (as the original resource) but resolves to an ssl cert or different ciphersuite to that of the original resource (identified by the user cert), what does one do? > > I’m unclear as to what you mean by "resolves to an SSL cert or different ciphersuite“; last I looked WebID didn't really care whether the resource was served over HTTPS or not to begin with. Mo agree with your points, but just thought I'd point out that I added http://bblfish.net/tmp/2011/11/23/index-respec.html# in the WebID Certificate Section [[ This URI should be one of the URIs with a dereferenceable secure scheme, such as https:// . Dereferencing this URI should return a representation containing RDF data. For example, a certificate identifying the WebID URIhttps://bob.example/profile#me would contain the following: ]] The point is if we don't put SHOULD here, then we're open to lots of FUD by security folks. People can use http URIs but then there are a lot less security guarantees. For that I added and in 3.2.4 [[ The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that WebID. An https WebID will therefore be a lot more trustworthy than an https WebID by a factor of the likelyhood of man in the middle attacks. ]] Henry Social Web Architect http://bblfish.net/
Received on Wednesday, 23 November 2011 14:51:08 UTC