- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 9 Jan 2012 22:44:14 +0100
- To: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-xg-webid@w3.org
On 9 Jan 2012, at 22:27, Jürgen Jakobitsch wrote: > henry, it's slightly different, > > i fixed a bug, that my NoRSAPublicKeyFoundException was NOT thrown, > in case of no statements about the claimed webID were found (a white screen was shown) > > i'm using HttpURLConnection that sends #s to nowhere :) and i didn't have any problem with hashes ever. > > sample : > > 1. in the cert there is the claim "http://2sea.org/sea.rdf#j" (please notice that this is sea.=> rdf <= and not the famous sea.jsp#j example) $ curl http://2sea.org/sea.rdf | cwm --rdf --n3 @prefix : <http://www.w3.org/ns/auth/cert#> . <http://www.2sea.org/sea.rdf> a <http://xmlns.com/foaf/0.1/Person>; :key [ a :RSAPublicKey; :exponent 65537; :modulus """e108c495f7006a5c30af4fd19c3508a7 cfdccc50cc6f0683409fb81e67c89ec9 efb8c8cbe28fd7556e1bf4fa271f93a5 e626ec9d3f4ac80223eebd1937121221 ff4aa2b80fa8e6c38428c3ddc352d54a 62109f20ab8caa246600489fa3b5776d 8b6698a3044fe4503b0e170cb5896696 a37652a2f5c94347fecb97bef79bf191 6a2145d7644c6c83af122678a185d542 73adca9d8f63cc27d33dd95b51355b87 bd9ebadfba8ca69b1f004eb2fb119899 698519efa3f273c482c32ed907ada48f df6639b97d6cef3e92005605c97a2855 a5d13f7311b758781d5b07c93c9eb0b9 52ab69b017f5d0869ecf185f934a0e4f 54fcfc4703ad86de5613986e258d8167"""^^<http://www.w3.org/2001/XMLSchema#hexBinary> ]; <http://xmlns.com/foaf/0.1/depiction> <http://www.turnguard.com/000001.jpg>; <http://xmlns.com/foaf/0.1/name> "jakobitsch jürgen" . You still have the problem with the white space in the modulus? Do you think we should ask the xsd:hexBinary people to change their definition? or do you think it is ok to parse this? Any reason? I mean if it is ok to do this then that would be good to know. > 2. look at the source of the above mentioned uri, there is NO statement about "http://2sea.org/sea.rdf#j" but only about "http://2sea.org/sea.rdf". yes I see. So, you are saying you are a document. Why do you want to do that? $ curl -I http://2sea.org/sea.rdf HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"1808-1326108943000" Last-Modified: Mon, 09 Jan 2012 11:35:43 GMT Content-Type: application/rdf+xml Content-Length: 1808 Date: Mon, 09 Jan 2012 21:38:14 GMT 200 means it's an information resource. Still that's not so much WebID's problem as your problem later on, if people wish to distinguish between you and the document talking about you. > > when validating, we need to retrieve statements about the claim, only in the above example there are none. > > so this has nothing to do with sending or not-sending #, but it's simply about the fact there is nothing about the claim in the retrieved document, > in such a case now the NoRSAPublicKeyFoundException is correctly thrown. I think if you have an exception thrown it's more likely because your parser is not going to be parsing the hex currently. > > to me it's quite clear what kingsley intends (i think at least, please correct me if i'm wrong) : > > a distinction between the location of the WebIDClaim and the claim itself. i personally think we're doing it anyway > with the hashes, but it's not that clear, because the location and the claim look very similar. The question is what would it bring that distinction. Would it be able to do what he wants it to do. And since that is all not very clear it is difficult to judge. > > when you say i'm using the webidClaim http://2sea.org/sea.jsp#j then you ARE saying TWO things : first, where to find > the webIDClaim (@ http://2sea.org/sea.jsp) and second, what subject to look for @ the mentioned location (=http://2sea.org/sea.jsp#j) yes. And if you look at the RFC for URIs that's there since the beginning pretty much. So since we have this feature, why not use it. > > and i think he is referring to the possibilities that open up when this is not limited to hash-uris. All URIs can have hashes. It's part of the definition of URIs. > wkr j > > > > ----- Original Message ----- > From: "Henry Story" <henry.story@bblfish.net> > To: "Jürgen Jakobitsch" <j.jakobitsch@semantic-web.at> > Cc: "Kingsley Idehen" <kidehen@openlinksw.com>, public-xg-webid@w3.org > Sent: Monday, January 9, 2012 10:03:32 PM > Subject: Re: Matter of DN and what's possible > > > On 9 Jan 2012, at 19:53, Jürgen Jakobitsch wrote: > >> hi, >> >> just a short in-between-question : >> >> are we talking about something like the bug i fixed today (see one of my last mails) >> with this example-uri : >> >> webIDClaim (in the cert): http://2sea.org/sea.rdf#j >> >> where the location of document is @ http://2sea.org/sea.rdf but there are only statements about http://2sea.org/sea.rdf, >> in which case i could verify the claim, if i had two fields in the cert, the location of the document and resource which is >> to be verified? > > No, that bug was nicely fixed by your server removing the # from the URL as per HTTP spec. > > What Kingsely wants to do is still not clear. > > Henry > >> >> wkr j >> >> ----- Original Message ----- >> From: "Kingsley Idehen" <kidehen@openlinksw.com> >> To: public-xg-webid@w3.org >> Sent: Monday, January 9, 2012 7:42:27 PM >> Subject: Re: Matter of DN and what's possible >> >> On 1/9/12 1:35 PM, Henry Story wrote: >>> Ok. So now you have two URLs where before we had one. That is why the previous talk about URIs being a luxury does not make sense. Your solution requires more of them. >>> >>>>>>> And if it is a URL then why is that not just the place of a WebID then? >>>>> >>>>> Because you will ultimately quibble about its complexity. >>> Why, I have always supported multiple SANs in the certificate. No issue there. >>> >> One point re. the above. Imagine the following scenario: >> >> I have a sparql construct URL as my address (and compacted using a >> shortener), and a HTTP URI based Name as the subject Name. Both URIs >> placed in SAN of my x.509 cert. Would your verifier work? Do you deem >> this acceptable re. WebID spec as it currently stands? >> >> Note: the SPARQL URL resolves to a description graph. The other URI is >> the Subject described by said graph. >> >> -- >> >> 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 >> >> >> >> >> >> >> >> -- >> | Jürgen Jakobitsch, >> | Software Developer >> | Semantic Web Company GmbH >> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 >> | A - 1070 Wien, Austria >> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22 >> >> COMPANY INFORMATION >> | http://www.semantic-web.at/ >> >> PERSONAL INFORMATION >> | web : http://www.turnguard.com >> | foaf : http://www.turnguard.com/turnguard >> | skype : jakobitsch-punkt >> > > Social Web Architect > http://bblfish.net/ > > > -- > | Jürgen Jakobitsch, > | Software Developer > | Semantic Web Company GmbH > | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 > | A - 1070 Wien, Austria > | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22 > > COMPANY INFORMATION > | http://www.semantic-web.at/ > > PERSONAL INFORMATION > | web : http://www.turnguard.com > | foaf : http://www.turnguard.com/turnguard > | skype : jakobitsch-punkt Social Web Architect http://bblfish.net/
Received on Monday, 9 January 2012 21:44:49 UTC