Revision as of 01:39, 1 November 2007 by Admin (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

TrustVocabIssue

TrustVocabIssue

Current status: open Owner: danbri@rdfweb.org

This is a FoafVocab issue, documented as such by linking it from the IssueTracker page.

This was originally a duplicate of PgpVocabUndocumentedIssue -- changed to concern other issues specific to wot. --MortenFrederiksen

See also discussion thread on rdfweb-dev and the Semantic Web Publishing (SWP) vocabulary.

Contents

General Issues

The wot schema could do with some OWLification.

Several literal properties should be declared as datatype properties (as already indicated with a comment).

Perhaps some integration with iCal/RDF for signature events would be in order, also to be able to verify by e.g. codepiction that a signature event is reasonable.

Instances of PGP should be substituted with PGP/GPG or something similar, to avoid exclusion.

It seems tempting to relate the name, comment and email fields of a key to the user of the key instead of to the key itself, as it most often will be the same. That is, the name field of a key usually contains the name of its user. However, for agents with multiple keys this presents a problem, e.g. for FoafBot:

<PubKey>
  <hex_id>6C746DD1</hex_id>
  <identity>
    <foaf:Agent>
      <foaf:name>FOAFBot (#bots instance)</foaf:name>
      <foaf:mbox rdf:resource="mailto:foafbot@usefulinc.com"/>
    </foaf:Agent>
  </identity>
</PubKey>
<PubKey>
  <hex_id>6C7F734E</hex_id>
  <identity>
    <foaf:Agent>
      <foaf:name>FOAFBot (Key used by the OPN #foaf instance of FOAFbot)</foaf:name>
      <foaf:mbox rdf:resource="mailto:foafbot@usefulinc.com"/>
    </foaf:Agent>
  </identity>
</PubKey>

The above seems fine at first, but then we realize that the identifying properties of foaf:mbox causes the two agents to be merged, leaving a single agent with two names, and no way to differentiate between the two keys. It could be argued that foafbot shouldn't use the same email address for multiple instances, but this is how it is. The above should instead be expressed as follows:

<PubKey>
  <hex_id>6C746DD1</hex_id>
  <dc:title>FOAFBot (#bots instance)</dc:title>
  <identity>
    <foaf:Agent>
      <foaf:name>FOAFBot</foaf:name>
      <foaf:mbox rdf:resource="mailto:foafbot@usefulinc.com"/>
    </foaf:Agent>
  </identity>
</PubKey>
<PubKey>
  <hex_id>6C7F734E</hex_id>
  <dc:title>FOAFBot (Key used by the OPN #foaf instance of FOAFbot)</dc:title>
  <identity>
    <foaf:Agent>
      <foaf:name>FOAFBot</foaf:name>
      <foaf:mbox rdf:resource="mailto:foafbot@usefulinc.com"/>
    </foaf:Agent>
  </identity>
</PubKey>

When generating RDF automagically from keyrings, the name of the agent or the name of the key is not readily available, there is just one string. In that case, the name property should be assigned to the key, leaving it off the user, since the identifying foaf:mbox property on the user opens opportunities for others to state the (correct) name of the user.

Classes

The Endorsement class is currently commented out of the schema. Its purpose/meaning doesn't seem completely clear, but seems to serve as the type for objects of an assurance predicate, that is, documents that contain a detached ascii signature.

The User class should be a subclass of foaf:Agent instead of foaf:Person, to allow for bots like FoafBot to have their own key(s). This also fits somewhat nicer with the comment for the PubKey class, which currently states that it represents a person's or organization's PGP public key.

A new class EncryptedDocument would be handy, to serve as the type of objects of an encryptedTo predicate (see usage in PGP Encrypting FOAF Files). This would also help systems avoid republishing statements obtained from encrypted documents.

Instances of the PubKey class could be assigned a URI, in which case it should identify a document with the ascii version of the public key. Alternatively, the pubKeyAddress property could be relaxed and used for this.

Properties

The hex_id property may be considered to be an owl:InverseFunctionalProperty, but in reality there are only 16^8^ = 4.294.967.296 different IDs. As such, this property should not be declared as an IFP.

In contrast, the chances for a collision between two keys on the property fingerprint should be negligable, so this should be declared to be an IFP.

The property identity relates a key to its user, so this is essentially the inverse of PgpVocabUndocumentedIssue, and should be declared as such when that property is coined/implemented. identity should be declared as a owl::FunctionalProperty, since a key can only belong to one user (even if it's an organization or group).

The domain of the signed property should be PubKey, not User, as a user may have more than one key. This is also what is suggested by the wording in the associated comment.

The signerLongHexID property should be replaced simply with a signer property. Aside from name casing issues, it seems much better to have a property that relates the signature event to a key rather than to a literal. The referenced key should of course have a hex_id property itself. The signer property should thus have a range of PubKey instead of literal. Note that this does not make signer an inverse of signed, as signer relates a signature to the key that is used to sign the signee, the signed key.

The assurance property should have a range of foaf:Document, and either a similar range, or a range of the currently out-commented class Endorsement.

The property pubkeyAddress is currently being misused according to its definition, as it's being used both as a property off a foaf:Person and a PubKey, where it should be used as a property off a foaf:Document. It seems that the best way out is to assign it a domain of PubKey and to create a new property endorser, so that a document is related by assurance to an endorsement, which in turn is related to the signing key by endorser. The range of pubKeyAddress would then be foaf:Document, thus having it relate a public key to a document containing an ascii version of the public key, suitable for import into a key ring. This approach (endorser) also makes it possible for a document to have multiple signatures.

Continuing along the same lines, a property encrypter should be added to the schema, to relate an encrypted document to the key that has encrypted it. Domain should be EncryptedDocument, range should be PubKey.

The property encryptedTo, as exemplified in PGP Encrypting FOAF Files, should be included formally in the schema, with a domain of foaf:Document and a range of PubKey.

A Revised Schema

* Original wot schema
* Revised wot schema
* Prettier version

Complete Example

An example document utilizing all the classes and properties of the revised wot vocabulary.

<rdf:RDF xmlns="http://xmlns.com/wot/0.1/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<foaf:Document rdf:about="http://example.com/doc.html">
  <dc:title>Example Document</dc:title>
  <assurance>
    <Endorsement rdf:about="http://example.com/doc.html.asc">
      <dc:title>Detached signature for "Example Document"</dc:title>
      <endorser rdf:nodeID="KeyA"/>
    </Endorsement>
  </assurance>
</foaf:Document>
<PubKey rdf:nodeID="KeyA">
  <hex_id>3756EA0B</hex_id>
  <length>1024</length>
  <fingerprint>04FF F3AC 57DF 217C 6D38  3DBC 0110 FB92 3756 EA0B</fingerprint>
  <pubkeyAddress rdf:resource="http://foaf.dk/key.asc"/>
  <identity>
    <User>
      <foaf:name>Web Service (foaf.dk)</foaf:name>
      <foaf:mbox_sha1sum>a714a83db77c6ce85211beb56599adf2c4eaa62f</foaf:mbox_sha1sum>
    </User>
  </identity>
  <signed>
    <SigEvent>
      <signer rdf:nodeID="KeyB"/>
      <sigdate>2004-02-18</sigdate>
    </SigEvent>
  </signed>
</PubKey>
<PubKey rdf:nodeID="KeyB">
  <hex_id>E3C9EC9D</hex_id>
  <length>1024</length>
  <fingerprint>2A 99 C4 9F 34 82 AE CF  11 09 FA 52 A6 FF 2F C2</fingerprint>
  <identity>
    <User>
      <foaf:name>Morten Frederiksen</foaf:name>
      <foaf:mbox_sha1sum>65b983bb397fb71849da910996741752ace8369b</foaf:mbox_sha1sum>
    </User>
  </identity>
</PubKey>
<EncryptedDocument rdf:about="http://example.com/doc.asc">
  <dc:title>Example Encrypted Document</dc:title>
  <encryptedTo rdf:nodeID="KeyB"/>
  <encrypter rdf:nodeID="KeyA"/>
</EncryptedDocument>
</rdf:RDF>

When an issue is resolved or its status w.r.t. the FOAF spec changes, that changed state of affairs should be documented somewhere less transient than the wiki. See IssueTracker for more notes on issue management conventions.