W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

Re: Redirects continued -- was: Problem with certificate on home-grown WebID

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 21 Dec 2011 14:30:44 +0100
Cc: Carvalho Melvin <melvincarvalho@gmail.com>, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, foaf-protocols@lists.foaf-project.org
Message-Id: <D5499FC4-5549-45FC-845F-38F5D6B03790@bblfish.net>
To: Sebastian Trüg <sebastian@trueg.de>, public-xg-webid XG <public-xg-webid@w3.org>

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/
Received on Wednesday, 21 December 2011 13:31:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 December 2011 13:31:19 GMT