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 17:19:36 +0100
Cc: Sebastian Trüg <sebastian@trueg.de>, public-xg-webid XG <public-xg-webid@w3.org>, Carvalho Melvin <melvincarvalho@gmail.com>, "foaf-protocols@lists.foaf-project.org" <foaf-protocols@lists.foaf-project.org>
Message-Id: <16A4E9A7-43E8-4F0B-A61F-E41D8050290E@bblfish.net>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>

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 :-(

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/
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
> 
> 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/
Received on Wednesday, 21 December 2011 16:20:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 December 2011 16:20:24 GMT