Re: Matter of DN and what's possible

hi henry,


1. the hexBinary is not the problem of the test and bugfix i mentioned.
   (the openrdfparser parses the hexBinary with or withoutspaces anyway)
2. the hexBinary is secondly not the problem of the bugfix i mentioned, because
   i have http://2sea.org/sea.rdf#j in my cert and all statements in the document
   are about the subject => http://2sea.org/sea.rdf <=
3. lastly the i'm using openrdf-sesame's api to parse.
4. the contents of the file are obviously for testing particular parts of the testServer.
5. no one is saying that hash-uris shouldn't be used.
6. i'm sure there are many usage scenarios, one that comes to mind is that you can have your webIDProfile 
   in whatever kind of triple store and make use of the triples that come with it also when not having a sponger
   at hand. say you have a cheap openrdf-sesame server and want to make use of the foaf:profiles for internal
   use also (in a company). how would you publish the profiles of the employees of a company without
   duplicating them or writing a service that makes available under their respective uri.

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:44:14 PM
Subject: Re: Matter of DN and what's possible


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/


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

Received on Monday, 9 January 2012 22:12:46 UTC