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

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

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/
> 
>