W3C home > Mailing lists > Public > public-webid@w3.org > April 2013

Re: Domain of :key

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 1 Apr 2013 21:15:18 +0200
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, public-webid <public-webid@w3.org>
Message-Id: <BDCBDCE9-D6B4-4077-AF7F-D46743D86E40@bblfish.net>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>

On 1 Apr 2013, at 21:03, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:

> On Mon 2013-Apr-01, at 08:39, Henry Story <henry.story@bblfish.net> wrote:
>> You should discuss that with Dan Brickley on the foaf mailing list if you think his definition is
>> so close to being a owl:Thing that it's not worth having the distinction.
> It isn't as it's used now. I'm saying it could well be if I described everything which could conceptually have an associated key(pair) as an agent. it's putting the cart before the horse.
>> We don't assign the domain of :key or the range of :identity to any agent, but to those
>> for which the following is true:
>> :identity a rdf:Property, owl:ObjectProperty;
>>   vs:term_status "archaic";
>>   rdfs:label "identity"@en;
>>   rdfs:isDefinedBy <cert#>;
>>   skos:editorialNote """
>>        It turns out that this relation is unintuitive to write out and to name.
>>        One should instead use cert:key
>>   """@en;
>>   rdfs:comment """
>>   the identity of the public key. This is the entity that knows the private key and
>>   so can decrypt messages encrypted with the public key, or encrypt messages that can
>>   be decrypted with the public key.
>>   """@en;
>>   owl:inverseOf :key;
>>   rdfs:domain :PublicKey .
>> That is it has to be something that can be responsible for a private key - keeping
>> it safe from other agents within reason, and it has to be something that can encrypt
>> and decrypt messages with the key. Those are very clearly agent like things.
>> Software agents can be such things.
> So I think perhaps the issue here is that this is an ontology specified for the benefit and purposes of WebID, but the 99% of the mechanics of it (not to mention the name) are entirely generic. Is this 'a cert ontology', or is this 'the WebID (certificates and keys) ontology'? If it's the latter, then it seems to me that there should be a somewhat more generically-focussed equivalent — but then things get messy.

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

So yes, we can model X509 correctly ( as far as one can model something that
is so old and cluncky) using our current ontology. 

>>> This is the distinction, I guess, between 'is defined as an agent' and 'has the properties of an agent' — and I suppose why X.509/LDAP has a distinction between 'structural' and 'auxiliary' classes (the former being defining qualities, the latter describing facets).
>>> What about, say, a piece of digital media? There are situations where encoded media has its own keys conforming otherwise to the ontology, and it's a bit of a stretch to say that *it* is an agent.
>> Does digital media also have its private keys with which it can sign something? Is Holloywood going to
>> encrypt digital media and add the private key to the media too, so that the media can then do what?
>> Clearly not. So they don't conform to the ontology
> Not autonomously: that's rather the point. If they were autonomous, they would be agents! The point is that they have associated keys (they belong conceptually more to the encoded media itself than to anything you'd define as an agent per se).

what is the relation? Is it that the media was encrypted with that key?
Then perhaps we need a cert:encryptedWith relation?
Is it that it was signed with that key then perhaps we need a cert:signedWith relation.

>> But perhaps this will become more obvious if you give us the use case. My guess is that this
>> will reveal that you need a very different relation. And I am not against that.
> Off the top of my head, "the thing which this key belongs to" — which may be an agent or may not.

Why do you want this vagueness? I have no idea what the use case is. Please give specifics.

> I'm not sure why you think that (aside from the cert:key domain in question) I'd want something other than cert:key for associating a cert:PublicKey or cert:PrivateKey with an entity which is considered to "own" it, be that sshd on a particular host, a Blu-Ray player, or my next-door neighbour.

So we can create a new relation. Perhaps by looking at it carefully we'll see that your current
argument is correct. But I have not idea why you think it is now.

>>> Flipping this around the other way, why _should_ the domain be restricted to foaf:Agent? What practical problems does it cause? (Noting that this isn't necessarily modifying the definition of a WebID, just that anything can have a key or even a certificate associated with it).
>> Because we want a relation relating the Agent that is doing the encryption decryption using the given key.
> You already know whether the thing associated with a key is an Agent or not, considering that it's the object in the cert:key triple…

That's not a reason to weaken the relation. This would require changing the definition.

> Perhaps more to the point, there's little in WebID which actually cares who is doing the encryption or decryption mainly because nobody who holds a WebID actually does that themselves.

No, the whole point of webid is that the agent controls the key. And furthermore I think we
are correctly modelling X509.

I have a feeling I have argued this at least 4 or 5 times now. 

Please bring new arguments to bear to the issue. Most of all detailed use cases.


> M.
> --
> Mo McRoberts - Analyst - BBC Archive Development,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------

Social Web Architect

Received on Monday, 1 April 2013 19:15:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:50 UTC