- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 21 Dec 2011 12:13:58 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4EF213D6.7020507@openlinksw.com>
On 12/21/11 11:19 AM, Henry Story wrote: > 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 But this is an implementation flaw. You are supposed to de-reference URIs. You shouldn't assume the level of indirection between a URI and an actual Resource. Just de-reference the URI leaving HTTP do the REST. > > >> 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.... Come on! > > 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? Please talk about URIs. The publisher of a URI is the one that determines how it resolves. That isn't for any user agent to decide. Speak HTTP that's it. Kingsley > > > 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/ > > > -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 21 December 2011 17:14:25 UTC