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

Re: design issue when dereferencing a foaf-profile with public key

From: bergi <bergi@axolotlfarm.org>
Date: Thu, 29 Sep 2011 23:43:23 +0200
Message-ID: <4E84E67B.20309@axolotlfarm.org>
To: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
CC: public-xg-webid@w3.org
btw. We have an issue "define an inverse of cert:identity" [1].

[1] http://www.w3.org/2005/Incubator/webid/track/issues/11

Am 29.09.2011 23:36, schrieb Jürgen Jakobitsch:
> hi again,
> 
> i should have read the spec-draft more carefully.
> 
> see 2.1. here http://www.w3.org/2005/Incubator/webid/spec/
> 
> WebID Profile :  A structured document that contains identification
> credentials for the Identification Agent...
> 
> wkr http://www.turnguard.com/turnguard
> 
> 
> 
> 
> ----- Original Message ----- From: "Jürgen Jakobitsch"
> <j.jakobitsch@semantic-web.at> To: "Kingsley Idehen"
> <kidehen@openlinksw.com> Cc: public-xg-webid@w3.org Sent: Thursday,
> September 29, 2011 10:41:05 PM Subject: Re: design issue when
> dereferencing a foaf-profile with public key
> 
> hi again,
> 
> that's exactly what i was talking about, there's no path directed
> from the foaf:Person into the direction of the RSAPublicKey, only one
> that is directed from RSAPublicKey to the foaf:Person : that's why i
> was asking if a predicate like hasRSAPublicKey would help, please
> also note that i sayd below that "there's no statement about the
> foaf:Person indicating where to find the RSAPublicKey"
> 
> i removed my public key from http://www.turnguard.com/turnguard and
> put it elsewhere. if i gave you the url (uri) of my public key now,
> it wouldn't test what i'm talking about, because when logging in
> using a certificate, the only uri i have is the one from the
> foaf-profile.
> 
> if you find my public key, congrats and i owe you a drink.
> 
> nevertheless i would have to consider this a trick on application
> level. the webID spec can hardly say that implementors should have a
> lod cache at hand..
> 
> please also note that i cannot log in now @ fcns.eu for example,
> which is no surprise.
> 
> 
> enjoy http://www.turnguard.com/turnguard
> 
> ----- Original Message ----- From: "Kingsley Idehen"
> <kidehen@openlinksw.com> To: public-xg-webid@w3.org Sent: Thursday,
> September 29, 2011 9:46:54 PM Subject: Re: design issue when
> dereferencing a foaf-profile with public key
> 
> On 9/29/11 3:04 PM, Jürgen Jakobitsch wrote:
>> hi kingsley,
>> 
>> thanks for your reply, may i ask, how you would find the publickey
>> of the following fictional foaf-profile :
>> 
>> <foaf:Person rdf:about="http://www.someuri.org/card#me"> ... 
>> </foaf:Person>
>> 
>> <rsa:RSAPublicKey rdf:about="http://www.public-keys.net/2342"> 
>> <cert:identity rdf:resource="http://www.someuri.org/card#me"/> 
>> </rsa:RSAPublicKey>
>> 
>> when these resources are dereferenceable under their respective
>> uri and my certificate states that the subject's UID is
>> http://www.someuri.org/card#me and there's no statement about the
>> foaf:Person indicating where to find the RSAPublicKey.
>> 
>> i cannot quite believe you crawl the whole lod cloud to find a
>> statement ?x cert:identity http://www.someuri.org/card#me
>> 
>> maybe i just have a knot somewhere in my brain...
>> 
>> any pointer very welcome wkr http://www.turnguard.com/turnguard
> 
> Why don't you post the URLs of the two resources. Then lets see if I
> can use SPARQL to get you a match.
> 
> If there is a path connecting the two resources hosting the
> relations, the Virtuoso's SPARQL can find it.
> 
> Also note, we have a living agent on the Web called URIBurner
> (curated by its users since 2007), we host a massive LOD Cloud Cache
> (29 Billion+ Triples), these things are all hooked together is Webby
> ways.
> 
> So you can send me the URLs, or hopefully I've added some clarity to
> the nascent puzzle :-)
> 
> Kingsley
>> 
>> 
>> ----- Original Message ----- From: "Kingsley
>> Idehen"<kidehen@openlinksw.com> To: public-xg-webid@w3.org Sent:
>> Thursday, September 29, 2011 8:34:36 PM Subject: Re: design issue
>> when dereferencing a foaf-profile with public key
>> 
>> On 9/29/11 2:06 PM, Jürgen Jakobitsch wrote:
>>> hi all,
>>> 
>>> i have a question concerning linked data principles and a
>>> dereferencing a foaf-profile with a public key.
>>> 
>>> currently it is apparently necessary that two (=2) resources are
>>> dereferenceable under one (=1) (the foaf:Persons's) uri. that is
>>> because there's no predicate linking from a foaf:Person to a
>>> RSAPublicKey. I could have a RSAPublicKey available at some-uri
>>> stating that it's cert#identity is some remote resource, which
>>> would be totally legal linked data, but when using the foaf uri
>>> from a certificate there's no chance i find the coresponding
>>> RSAPublicKey.
>> You assume that there are no WebID authentication/verification
>> protocol implementations that also include follow-your-nose
>> crawling :-)
>> 
>> FYI -- that's integral to Virtuoso's WebID implementation. It even 
>> includes reasoning and transitive closures at LOD scales.
>>> 1. has this issue already been discussed?
>> Yes, there was a thread between Peter Williams and I about this.
>> He raised this matter way back, so to speak.
>> 
>>> 2. is it not considered an issue but simply the way it is? 3.
>>> would a predicate like "hasPublicKey" improve things?
>>> 
>>> any comment or opinion really appreciated wkr
>>> http://www.turnguard.com/turnguard
>>> 
>>> 
>> 
> 
> 
> --
> 
> Regards,
> 
> Kingsley Idehen President&  CEO OpenLink Software Web:
> http://www.openlinksw.com Weblog:
> http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: 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
> 
> 
Received on Thursday, 29 September 2011 21:43:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 September 2011 21:43:51 GMT