Re: Domain of :key

On 29 March 2013 13:21, Henry Story <henry.story@bblfish.net> wrote:

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

good


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

fine


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

why could you not?  you just did


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

eiffel tower has a public key ... not sure it's problematic


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

Are you saying that people are making inferences on the :key relation to
assume the subject is an agent, and that, that is your objection?


>
> ie: you can't put:
>
> <#me> mlv:key key.
>
>     you need to write
>
> <#me> a foaf:Agent;
>           mlv:key key .
>

surely this is good practice anyway, a subject should specify a type, we do
think in JSON-LD with @type, for example

is this your objection?


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

sure, but does not make the question invalid


>
> For reference currently we have:
>
>   119 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l119> :key a owl:InverseFunctionalProperty;
>
>    120 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l120>     vs:term_status "unstable";
>
>    121 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l121>     rdfs:label "key"@en;
>
>    122 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l122>     rdfs:isDefinedBy <cert#>;
>
>    123 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l123>     owl:inverseOf :identity;
>
>    124 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l124>     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
>
>    125 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l125>     rdfs:domain foaf:Agent;
>
>    126 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l126>     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.
>

I'm still trying to work out where (if at all) ... we're getting closer it
seems.


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

If I can clarify the situation it will be possible to build a proof of
concept.  Running code is always a help in achieving consensus.

In short, I'm unsure you've raised a compelling objection, base on any
concrete cases.

So far on this thread there's

in favour of rdfs : Resource +2
In favour of foaf : Agent +1


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