[foaf-protocols] The case for massive simplification and foaf:key

[Nathan]

Hi All,

I've been discussing off-list with Melvin and various others over the 
past few months about many future uses of webid, public keys and various 
implications of the way we are currently doing things.

To start, here's the proposal:

  :me foaf:key "DER-formatted-public-key"^^xsd:base64Binary .

Verbally:
To remove all usage of cert,rsa etc from the webid protocol and replace 
with a single foaf:key property, the value of which is a DER formatted 
Public Key.

Recognition:
Henry, in no way does this reflect poorly or undermine you or your work, 
I'm sure I won't be alone in saying that you've made an outstanding 
effort thus far, with much personal sacrifice to bring something to the 
web which we will all be forever grateful for, it's not often somebody 
can "change the game" as much as you have. Similarly this is just a 
proposal for discussion and every con/objection should be aired. (Can 
you tell I feel a bit awkward making such a big suggestion).


Reasons:
Only one triple, thus greatly simplifying the webid protocol for users, 
implementers, adopters and implementations, it's very very easy to 
understand and execute for all.

it speeds up implementations of the webid protocol exponentially, 
creating a very small memory footprint. To expand:
  - the current rsa+cert representation requires the entire document to 
be parsed and stored in memory in order to 'query' for a matching webid, 
often this will include a dependency on sparql, and when done with only 
native code procedurally is quite complex (although do-able), this is 
relatively heavy and can produce a high memory footprint.
  - the suggested foaf:key proposal requires no data storage or sparql 
implementation, all that is required is an RDF Parser, further if that 
parser implements a streaming API then (this part of the) webid protocol 
can be implemented with no more than a simple parser filter along the 
lines of:
  if(t.property = 'foaf:key' && t.subject = webid && t.object = key)
    return true;
  return false;
This will exponentially decrease both the memory footprint of 
implementations and execution time of a webid implementation.
  - if a streaming api is not used then this part of the protocol can be 
implemented with a simple fast existential quantification test, such as:
   RDFStore.some(filterFromAbove);
again this offers significant speed increases and removes any real or 
implied sparql dependency / usage.
- if sparql is used, then a very simply ASK query can be used to see if 
the triple { webid foaf:name key } exists.


WebID protocol already has a dependency on FOAF
the FOAF vocabulary is wide spread, introducing foaf:key and thus WebID 
protocol in to foaf will increase the exposure of WebID protocol massively.
WebID Protocol and foaf:key will bring many benefits to FOAF, including 
adding addition weight to the "how do I use this in a user system?" and 
"why should I use this?" questions would be adopters have.
allows users to get going with web 3.0 / decentralized social networking 
(FOAF+SSL!) with a single familiar and easy to use ontology.
Placing in FOAF means it's at least 2 less ontologies to dereference at 
runtime, and for implementers to support and understand.
It's a natural home!

DER is a near ubiquitous defacto format for public keys and widely 
supported in almost every language / runtime.
PEM *is* DER wrapped in some human readable text, strip the text and you 
have a DER (hence the above statement).
DER allows us to simplify down to a single triple.
Implementations will often have to do no heavy lifting / parsing as the 
native language libs or runtime will offer PEM/DER formatted Public Key 
support.

Compatibility, two fold, in one sense as mentioned it allows the public 
key to be used thus allow serendipitous invention of new and brilliant 
uses of the foaf:key, in another sense it means webid protocol is 
natively compatible with many other public key based "things" from 
github/hg through to full WOT and all in between; complementing this it 
points everything towards FOAF profiles and a web of linked data, get a 
profile, stick your key in it, use it for anything!
As a simple example of scope, I could simply pull your foaf:key, use it 
to seal a message and then save it in public on the web, knowing that 
only you could view the sealed data. I could sign documents I've created 
on the web (where i am dc:creator) and simply stick the hash in my FOAF
   { http://ex.org/some#post :signature "FD.." }
then everybody on the web could verify that I did indeed create/own the 
document and that it hadn't been tampered with. Millions of other use 
cases, many of which will be far more exciting and clever than these.

I'm sure there are more benefit and some cons (can't really think of any 
tbh, maybe BC but there are how many of use with webid's and support?), 
  hopefully that's enough for us to consider the proposal and get 
discussing.

Best,

Nathan