Re: [foaf-protocols] Redirects continued -- was: Problem with certificate on home-grown WebID

On 12/21/11 12:12 PM, Henry Story wrote:
>
> On 21 Dec 2011, at 18:05, Peter Williams wrote:
>
>> Our colleague from the BBC already made the case for redirects.
>>
>> The case is just normal, in larger websites. The content producer and 
>> the content manager are different parties, in the publishing world. 
>> Content manager get to reorganize links, as they control when and if 
>> content gets un/published, and where it gets re-published.
>>
>> The question is, what does the spec say about the security threats, 
>> and what are the counter measures?
>
> Well since you have been in the security space for so long, can you 
> come up with some security
> threat scenarios? Start with simple ones, that we can answer, and lets 
> see if we can build
> more complex ones that are problematic.
Henry,

If you don't know of any threats that are unique to WebID re. HTTP why 
are you using it as a weak excuse for veering WebID away from AWWW? This 
spec cannot be kind of compliant with AWWW . It either conforms or it 
doesn't. No ambiguity allowed.

Kingsley
>
>
> Henry
>
>>
>>
>> > From:henry.story@bblfish.net <mailto:henry.story@bblfish.net>
>> > Date: Wed, 21 Dec 2011 17:19:36 +0100
>> > To:pierre-antoine.champin@liris.cnrs.fr 
>> <mailto:pierre-antoine.champin@liris.cnrs.fr>
>> > CC:foaf-protocols@lists.foaf-project.org 
>> <mailto:foaf-protocols@lists.foaf-project.org>;public-xg-webid@w3.org 
>> <mailto:public-xg-webid@w3.org>;sebastian@trueg.de 
>> <mailto:sebastian@trueg.de>
>> > Subject: Re: [foaf-protocols] Redirects continued -- was: Problem 
>> with certificate on home-grown WebID
>> >
>> >
>> > On 21 Dec 2011, at 16:57, Pierre-Antoine Champin wrote:
>> >
>> > > Hi,
>> > >
>> > > I had the same misunderstanding as Sebastian, creating WebID
>> > > http://champin.net/pa
>> > >
>> > > I now created
>> > > http://champin.net/#pa
>> > > (which I too prefer, btw).
>> > >
>> > > But that one does not work with foafssl.org <http://foafssl.org> :-(
>> >
>> > That's because at present it does not have redirection implemented 
>> and you resource redirects
>> >
>> > $ curl -i http://champin.net/
>> > HTTP/1.0 302 Found
>> > Server: BaseHTTP/0.3 Python/2.5.2
>> > Date: Wed, 21 Dec 2011 16:15:10 GMT
>> > Location: http://liris.cnrs.fr/~pchampin/ 
>> <http://liris.cnrs.fr/%7Epchampin/>
>> > Content-type: text/html
>> > Vary: Host
>> >
>> >
>> > > I attach the result page. It says
>> > >
>> > > The WebId Profile must be parseable Content and transformable to an
>> > > RDF graph
>> >
>> > yep, if I were to be serious about redirects I'd have to change that 
>> to say: we don't work with
>> > redirects....
>> >
>> > Since we are looking for use case for webids that redirect, let me 
>> ask you: why did you find
>> > it important to have your webid redirect?
>> >
>> >
>> > Henry
>> >
>> > >
>> > > but RDF Validator is happy with it:
>> > >
>> > > 
>> http://www.w3.org/RDF/Validator/ARPServlet?URI=http%3A%2F%2Fchampin.net%2F&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED 
>> <http://www.w3.org/RDF/Validator/ARPServlet?URI=http%3A%2F%2Fchampin.net%2F&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED>
>> > >
>> > > and it is recognized by https://auth.fcns.eu/
>> > >
>> > > pa
>> > >
>> > >
>> > > On 12/21/2011 02:30 PM, Henry Story wrote:
>> > >>
>> > >> On 21 Dec 2011, at 14:05, Sebastian Trüg wrote:
>> > >>
>> > >>> On 12/21/2011 11:19 AM, Henry Story wrote:
>> > >>>>
>> > >>>> On 21 Dec 2011, at 09:55, Sebastian Trüg wrote:
>> > >>>>
>> > >>>>> Attached you find the result from 
>> https://foafssl.org/test/WebId. To be
>> > >>>>> honest I am not sure if it succeeded or not, the output 
>> confuses me. :/
>> > >>>>
>> > >>>> yes, the output of this test suite is not as well finished as 
>> the previous
>> > >>>> one. And there is a bug there, I'll fix.
>> > >>>>
>> > >>>> Ok, so you are using a WebID that redirects. I would suggest 
>> against it for
>> > >>>> two reasons:
>> > >>>>
>> > >>>> -1. It increases the verification time for the verifier: the 
>> verifier has
>> > >>>> to potentially do 2 HTTP connections, and in any case it has to 
>> do back
>> > >>>> and forth
>> > >>>> -2 It is possible that some implementations don't support 
>> redirect, as it is
>> > >>>> one of these less obvious features of the web. As soon as you 
>> add complexity
>> > >>>> you add ways things can go wrong, and your identity is perhaps 
>> important
>> > >>>> enough for you not to want these things to go wrong
>> > >>>> (In this case my implementation does not support it. But I can 
>> add it)
>> > >>>> -3 We believe we have worked out the security characteristics 
>> of redirects,
>> > >>>> but they are less obvious than the simple GET and will require 
>> more work,
>> > >>>> so we have no language in the spec at present covering those - 
>> it's undefined
>> > >>>> one might say. In any case they confuse Peter Williams, and 
>> risk confusing
>> > >>>> military grade security people a lot more. So if you want to 
>> log in to higher
>> > >>>> security sites you may find redirects create confusion with 
>> those people
>> > >>>> implementing them. This comes up in ISSUE-64
>> > >>>> http://www.w3.org/2005/Incubator/webid/track/issues/64
>> > >>>>
>> > >>>> Does that make sense?
>> > >>>
>> > >>> Well, yes. However, I am confused. You directed me to the site 
>> which I
>> > >>> took this setup from.
>> > >>
>> > >> http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/
>> > >>
>> > >> Yes, it is true that the "Best Practice Recipes for Publishing 
>> RDF Vocabularies"
>> > >> covers two cases one of which uses a redirect. The redirect is as 
>> we mentioned
>> > >> may require us to think things through in a bit more detail, 
>> though I don't think
>> > >> it is a big issue.
>> > >>
>> > >>> Also you mentioned that it would be nicer to have
>> > >>> web ids like http://www.trueg.de/sebastian instead of something like
>> > >>> http://www.trueg.de/sebastian/foaf[#me].
>> > >>
>> > >>> So which is it? :)
>> > >>
>> > >> I think I mentioned WebIDs like
>> > >>
>> > >> http://www.trueg.de/sebastian#me
>> > >>
>> > >> rather than
>> > >>
>> > >> http://www.trueg.de/sebastian.rdf#me
>> > >>
>> > >> not
>> > >>
>> > >> http://www.trueg.de/sebastian
>> > >>
>> > >> with a redirect.
>> > >>
>> > >> I think there is a pragmatic consideration in favour of the # one 
>> to do with reduction
>> > >> in communication costs.
>> > >>
>> > >> But you are right that this would do well to be more clearly 
>> specified in the
>> > >> spec.
>> > >>
>> > >>>
>> > >>>> So having said that there are a number of redirect types,
>> > >>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>> > >>>>
>> > >>>> 300 Multiple Choices
>> > >>>> 301 Moved Permanently
>> > >>>> 302 Found // we can ignore this one
>> > >>>> 303 See Other
>> > >>>> 304 Not Modified
>> > >>>> 305 Use Proxy
>> > >>>> 307 Temporary Redirect
>> > >>>>
>> > >>>> and one needs to consider which of these have what types of 
>> security implications, if any.
>> > >>>> Perhaps there is not much more to do here than to just think it 
>> though. But if we want to
>> > >>>> help implementors implement the WebId protocol so that you get 
>> a consistent experience between
>> > >>>> each verification service, and so that you are not left out in 
>> the cold inexplicably
>> > >>>> some places and not others, then we need to work this out. As 
>> you see it is easier and more
>> > >>>> efficient to stick to #urls.
>> > >>>>
>> > >>>> The question is if there are any good rason for non #urls in 
>> our authentication use case.
>> > >>>
>> > >>> Only the prettyness of the URL which should be irrelevant in the end
>> > >>> since the point is to not show it to the user, right.
>> > >>
>> > >> yes, that alone would not make for a very good reason. Perhaps 
>> there are others. It would
>> > >> be good to collect them.
>> > >>
>> > >>> I simply followed your advise, or maybe misunderstood your advise...
>> > >>
>> > >> No you are doing well :-) You're helping us think about this 
>> issue 2^6 here. It's an important
>> > >> one.
>> > >>
>> > >> Henry
>> > >>
>> > >>>
>> > >>> Cheers,
>> > >>> Sebastian
>> > >>>
>> > >>>> Henry
>> > >>>>
>> > >>>>>
>> > >>>>> Cheers,
>> > >>>>> Sebastian
>> > >>>>>
>> > >>>>> On 12/20/2011 10:44 PM, Henry Story wrote:
>> > >>>>>> Ok, I have updated the server to the new scala version.
>> > >>>>>>
>> > >>>>>> I hope it remains up until you read this e-mail. I am still 
>> working on the details
>> > >>>>>> of how to release it. But if it is still up please let me 
>> know if it works now
>> > >>>>>> with your key.
>> > >>>>>>
>> > >>>>>> Henry
>> > >>>>>> [snip]
>> > >>>>
>> > >>>> Social Web Architect
>> > >>>> http://bblfish.net/
>> > >>>>
>> > >>>>
>> > >>
>> > >> Social Web Architect
>> > >> http://bblfish.net/
>> > >>
>> > >>
>> > >
>> > > <WebId.html>
>> >
>> > Social Web Architect
>> > http://bblfish.net/
>> >
>> > _______________________________________________
>> > foaf-protocols mailing list
>> >foaf-protocols@lists.foaf-project.org 
>> <mailto:foaf-protocols@lists.foaf-project.org>
>> >http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org 
>> <mailto:foaf-protocols@lists.foaf-project.org>
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen