Re: Domain of :key

On 29 Mar 2013, at 11:11, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 29 March 2013 11:01, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 29 Mar 2013, at 10:50, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> 
>> On 29 March 2013 10:41, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 29 Mar 2013, at 10:25, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>> 
>>> 
>>> 
>>> On 29 March 2013 09:52, Henry Story <henry.story@bblfish.net> wrote:
>>> 
>>> On 29 Mar 2013, at 09:21, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 29 March 2013 09:14, Henry Story <henry.story@bblfish.net> wrote:
>>>> 
>>>> On 29 Mar 2013, at 08:53, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 29 March 2013 08:37, Henry Story <henry.story@bblfish.net> wrote:
>>>>> 
>>>>> On 22 Mar 2013, at 10:42, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>>> 
>>>>>> Currently we have:
>>>>>> 
>>>>>>     rdfs:domain foaf:Agent;
>>>>>> 
>>>>>> This seems slightly restrictive. 
>>>>>> Many things can have a key, e.g. a certificate, an account, an app etc.  Agent perhaps does not cover every conceivable use case?
> 
> We are not here to cover every conceivable use case. That would be absolutely impossible to do.
> 
>>>>> 
>>>>> You can create new relations to relate those things to keys if you need to.
>>>>> 
>>>>>   foaf:primaryTopic can relate a document keys it is about for example.
>>>>> 
>>>>> We need a relation to relate the agent that is the one that controls the private key
>>>>> of the public key to the public key, as that is what WebID authentication and most
>>>>> other protocols need to work.
>>>>> 
>>>>> In bitcoin users have a pseudo anonymous account.  Each account has a key pair.  It would be great to be able to model this.
>>>> 
>>>> Why could one not think of an account as an Agent? It can transfer money, it can accept payments, etc... It is a micro agent related to you. 
>>>> 
>>>> Ah OK, if an agent can also be an account, that works.
>>> 
>>> It depends of course on what the bitcoint:Account thing is that you are speaking of.
>>> And one would need to  compare that to the definition of foaf:Agent.
>>> 
>>> Say for sake of argument that you think of such an account more as a bucket, in which you
>>> can add money like you could add water to a bucket, and from which you can remove money
>>> as you could pour water out of a bucket into someone else's glass. Here thinking of the bucket as
>>> an Agent does not sound right. 
>>> 
>>> This is a great analogy.  Each bitcoin account is like a bucket that contains 0 or more bitcoins.
>>> 
>>> It makes no assumptions whatsoever about ownership.  Indeed, there need be no concept of ownership.
>> 
>> There has to be a relation between an agent that knows the private key and can prove its ownership 
>> of that key, at least in so far as it signed the private key. That requires the relation between an agent 
>> and a key, which cert:key is about.
>> 
>> cert : key can be used for this.
>>  
>> 
>>>  
>>> 
>>> Then you can think of the access to the bucket as being restricted to certain
>>> agents. In which case you can use the Web Access Control vocabulary.
>>> 
>>>  http://www.w3.org/wiki/WebAccessControl
>>> 
>>> The wac ontology relates an Agent(a), a resource, and actions that can be done on those
>>> resources. 
>>> 
>>> So there are a number of ways of relating different things. One does not need to use cert:key 
>>> for each of these ways of relating them.
>>> 
>>> It would be great if I could say 
>>> 
>>> <> a foaf : OnlineAccount
>>>   cert : key [ ... ]
>>> 
>>> Independent of any ownership details.  
>> 
>> You can say that, but not with the cert:key relation. Changing the cert:key relation means
>> we then have to change all the specs.
>> 
>> I'd rather we now finish the specs as we have them, so that we can propose this to the
>> W3C for a Working Group. BitCoin can then join that Working Group by proposing a clear
>> use case, with an ontology that it is using, which can then be used to extend the ontology.
>> This XG is past the end of its life time, and this is not the time to make drastic revisions.
>> 
>> Yes totally agree we should move forward ASAP.
>> 
>> I think this is a minor bug fix.  The cert ontology is not about WebID it's about certificates and security.  We can fix it in the hg like we quickly fixed some bugs earlier this week, and added DSA.
>> 
>> Why do you think this is a drastic change, I dont think any implementations need change?
> 
> Because we have defined a WebID as an identifier for an Agent, not an identifier for any
> resource. We have defined WebID auth over TLS as identifying an Agent, that can prove
> the private key of the public key. Here we now need to add new text in every spec in order
> to speak about accounts. We would then need to rework all these specs. 
> 
> I'm trying to follow the logic here.  
> 
> Let's consider Mo's proposal just to widen the range to something like rdfs : Resource
> 
> A WebID can still be an agent, yes?

yes.

The problem is that you need to define how for some object X you relate it to the private key. 
In order to distinguish your definition from the current one, so that we don't have misunderstandings
let us call your relation mlv:key .

mlv:key a rdf:Property;
     rdfs:domain rdfs:Resource;
     rdfs:range cert:Key .

Now that means I can relate any object to a key. For example why could I not take the Eiffel Tower,
and write:

     dbpedia:EiffelTower mlv:key <http://bblfish.net/people/henry/card#key1> .

Good so now what kind of relation is that? What is the relation of the private key to the Eiffel
tower that we need in order to prove cryptographically the identity of a user of the key? You
want some kind of way of limiting what objects you can truthfully add the cert key relation to,
otherwise it is meaningless.

Perhaps I need a relationship of ownership to the EiffelTower to be able for the relation to the
agent to work?  Perhaps

mlv:owns a owl:InverseFunctionalProperty;
    rdfs:comment """
       an agent that owns according to all legal system the object. 
       (If we add relativity to a legal system things get more complicated)
    ";
    rdfs:domain foaf:Agent;
    rdfs:range rdfs:Resource .

So then we would have the rule

{ ?agent mlv:owns ?thing . ?thing mlv:key ?key } => { ?agent cert:key ?key } .

So your "simplification" in fact is going to create more complexity elswhere.
You could argue that when the ?thing is an agent it owns itself perhaps, and 
so that in that case it should fall out through reasoning. But now we have
introduced an "if x is an Agent then do Y else do Z" into our code everywhere,
and we need to specify everywhere that people have to write out for anything
they put a mlv:key on that they need to specify that it is a foaf:Agent.

ie: you can't put:

<#me> mlv:key key.

    you need to write 

<#me> a foaf:Agent;
          mlv:key key .

And none of this yet prooves that your hypothetical bitcoin example would not be 
better off with the cert:key relation. 

For reference currently we have:

  119 :key a owl:InverseFunctionalProperty;
   120     vs:term_status "unstable";
   121     rdfs:label "key"@en; 
   122     rdfs:isDefinedBy <cert#>;
   123     owl:inverseOf :identity;
   124     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
   125     rdfs:domain foaf:Agent;
   126     rdfs:range :Key, :PublicKey .

( It should say something about the control the agent has over the corresponding private key . 
  A previous version had that text in there. We seemed to have lost it.)


> 
> Why do you feel the webid spec would be forced to change.  Would leaving the text the same introduce a bug or inaccuracy?  My suggestion is to leave the webid specs the same.
>  
> 
> The WebAcessControl implementations and ontologies also need to be reworked sine 
> they are working in terms of agents.  
> 
> Why would WAC implementations need change?  Im unsure this is inaccurate.  Again I propose leaving implementations untouched.
>  
> 
> So you are asking us to revise something for a use case you call bitcoin for which we have
> no idea how they would write up their ontology, if they even need what you suggest they may
> need, etc... It's a lot of hypotheticals for something that is easy to add later with a new relation,
> or for which they may in fact be satisfied with what we have.
> 
> This is not use case driven.  I gave an example.  

You gave a use case yes. We don't know if the use case is best modelled the way
you are thinking of modelling it. That would require people to work on the bitcoin model
in detail, and they could end up being satisfied with the cert:key as it is now.

I think you need to prove that this cannot be the case. 

> 
> I repeat I think it's a bug in the cert ontology that would come up in an XG or WG.  
> 
> I may be wrong but I thought this was a simple fix.  

It looks simple, but it creates complexity elsewhere. 

>  
> 
> This is a lot of work, and until bitcoin is really sitting at the table, which they will only do 
> as part of a WG then we are just speaking hypothetically.
> 
> It need not be a lot of work.  Bug fixes in specs should have a fast turn around.

It is a hypothetical bug. You have suggested a modelling need for bitcoin. But there has
been no scrutiny of this. There cannot be: since the work has not been done. And the work
of doing this is not something that can be done on the back of an envelope in 5 minutes.

Henry

>  
> 
> So rather than do that, let's finish the specs, and get momentum for a Working Group.
> 
> henry
> 
>>  
>> 
>> Henry
>> 
>>>  
>>> 
>>> 
>>>>  
>>>> 
>>>>> 
>>>>> It's perhaps the most serious use of PKI on the web after ecommerce.
>>>>>  
>>>>> 
>>>>>> 
>>>>>> Is the parent of Agent an owl : Thing?
>>>>> 
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>>> 
>>> 
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/