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

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

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Wed, 21 Dec 2011 16:57:39 +0100
Message-ID: <4EF201F3.30000@liris.cnrs.fr>
To: Henry Story <henry.story@bblfish.net>
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>

I had the same misunderstanding as Sebastian, creating WebID

I now created
(which I too prefer, btw).

But that one does not work with foafssl.org :-(
I attach the result page. It says

  The WebId Profile must be parseable Content and transformable to an
  RDF graph

but RDF Validator is happy with it:


and it is recognized by https://auth.fcns.eu/


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/

Received on Wednesday, 21 December 2011 15:58:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:27 UTC