Re: Domain of :key

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. 

The WebAcessControl implementations and ontologies also need to be reworked sine 
they are working in terms of agents.  

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

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/