Re: Domain of :key

On 3 Apr 2013, at 17:52, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 3 April 2013 17:45, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 3 Apr 2013, at 17:39, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> 
>> 
>> On 1 April 2013 22:06, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 1 Apr 2013, at 21:45, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> 
>> > On 4/1/13 3:15 PM, Henry Story wrote:
>> >> We can add new relations. Just let us know what you want. I am not sure why you want to merge two relations. You have not explained this yet, nor have you given a full use case.
>> >>
>> >> As far as X509 goes if you look at it it is relating a DN and its subject alternative names to a public key.
>> >> If you think of that semantically that can be modelled as
>> >>
>> >> <> a X509Cert;
>> >>    foaf:primaryTopic<ldap://DN=....>  ;
>> >>  <ldap://DN=....>  owl:sameAs<https://my.domain.example/joe#me>;
>> >>     cert:key [ a cert:RSAPublicKey;
>> >>                cert:modulus "...";
>> >>                cert:exponent "..." ] .
>> >
>> > Why not:
>> >
>> > <#dnReferentID>
>> > <#hasKey> <#PublicKey> .
>> > <#sanReferentID>
>> > <#hasKey> <#PublicKey> .
>> >
>> > <#hasKey>
>> > a owl:InverseFunctionalProperty, owl:ObjectProperty .
>> 
>> If  <#hasKey> owl:sameAs cert:key, then what you wrote is equivalent
>> to what I wrote above.
>> 
>> Indeed the owl:InverseFunctionalProperty is essential, and it would not be true for a
>> cert:signedWith relation that we should probably coin. Because hopefully you can sign
>> more than one document with a key! The same would be true with a cert:encryptedWith relation,
>> as one would like to encrypt any number of documents with the same key.
>> 
>> Both something along the lines of a cert:signedWith and a cert:encryptedWith relatinon would
>> be very useful to have in the cert ontology. But they are clearly not going to be equivalent
>> to the cert:key relation ( or your <#hasKey> ).
>> 
>> >
>> > What's critical to WebID is the InverseFunctionalProperty relation semantics which help appreciate the optimal domain for <#hasKey> .
>> 
>> yes. Agree.
>> 
>> There need be no IFP between the key of a certificate and the Agent that uses/controls/uses that key.
>> 
>> I could think of a bunch of Agent robots sharing a high reputation certificate.  Indeed, an server side SSL certificate can be used as auth for many URLs at a given origin (ie domain) without those URLs being owl : sameAs each other.
>> 
>> IFP *may* be related to webid, but it's not related to certs.  I think there needs to be a round of looking at concepts modelled and coming up with the right names at some point.
> 
> In that case there is no way of distinguishing them cryptographically, and they are the same agent. There is nothing stopping you from having complex agents. foaf:Group is such a thing for example.
> 
> All correct, except for your inference that they are the same agent does not hold
> 
> 1) Why would you think there is no way to distinguish distinct agents with crypto

Nobody said so. We do this all the time with WebID.

> 2) Even if you cant distinguish with *crypto*, you can still distinguish agents

As you can imagine, nobody denies that.

> 3) That you are unable to distinguish agents does not imply they are the same

Nobody denies that.

The role of cert:key and cert:identity, is an affirmation that the agent the
agent that can prove he has the private key of the given public key is the agent identified
by the given WebID.

That's the game we have been playing since the beginning of WebID. 

> 
>  
> 
>>  
>> 
>> >
>> > Conclusion: we need to cater for the fact that public keys can (and will) be associated with all sorts of things (owl:Thing entity types) for a plethora of reasons. Thus, it's best veer away from generic terms (and resulting intuitions) when the usage purpose is very specific.
>> 
>> yes. I am in favor of adding relations such as signedWith or encryptedWith to the ontology.
>> 
>> Henry
>> 
>> >
>> >
>> >
>> > --
>> >
>> > 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
>> >
>> >
>> >
>> >
>> >
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/