[foaf-protocols] webid group said... something interesting

peter williams home_pw at msn.com
Wed Mar 23 08:58:38 CET 2011


So how can we engineer a trivial to execute means of populating a million
blog sites with a foaf card?

What 3 things things can a browser then do to enable it all?

Is there any way to let a person comment on given a blog site I - acting as
a request for a foaf card? The trackback or pingback to their own site at
URI u (for user) induces I (for issuer) to leave a certain paragraph of HTML
back on the users own blog site, populated with the RDFa tags publishing
their cert's pubkey etc. The card (within HTML paragraph tags, remember)
contains a URI in the homepage field - say - to the user's remote .p12 file,
generated under a standard password indicated in the URI path element.
http://peter.com/credentials.p12?yourpassword=snoopy

This is all very impure, insecure (in the .p12 sense) and would assuredly be
replaced by better implementations. But the assurance and strength of the
method don't matter; what matters is exposure and ease of adoption. To
handle the harassing journalist out to make hay, one shows that there other
implementations that add strength and assurance. For example, the xwiki
approach.

It just has to require almost nothing of the user. It has to be a drive-by
webid.

If I wanted 2  or 3 things of browser so as to *enable* webid I would want
for this some things that are not contentious (eliminates HTML5 keygen tag)
and which are minor variants of code already in production. They have to be
3 tweaks.

1. ensure in all browsers that .p12 extension and the .p12 mime type are all
consumed by the browser's key management module when the stream comes from
an HTTP resource. i.e. click on http://peter.com/file.p12 and the browser
gets certs/keys populated. User to be presented with usual dialog box to
enter password.

2. that all browers comprehend a local uri like "webid:about", which induces
the browser to bring to the foreground the user's key management module (the
prefs area about certs etc, in each browser design). This has to be
invocable by javascript.

3. an API method allowing a model plugin to enumerate the ssl sessionids in
use on the currently visible tab. A plugin has access to the state of each
session bound to the DOM of the tab, from which it can go make HTML content
for the associated client cert in that session state. This might include
finding the SAN URI, getting the associated HTML+RDFa, and presenting it in
a drop down rendered by the plugin/toolbar.

-----Original Message-----
From: Henry Story [mailto:henry.story at bblfish.net] 
Sent: Tuesday, March 22, 2011 4:44 PM
To: Kingsley Idehen
Cc: peter williams; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] webid group said... something interesting


On 22 Mar 2011, at 23:13, Kingsley Idehen wrote:

> On 3/22/11 4:46 PM, Henry Story wrote:
>> Also think how much responsibility Google has with the work it has
currently. For large companies like that some simple things become very
difficult: because you need to maintain the reliability on which your
reputation is built for example.
> Yep!
>> 
>> And then some things cannot be done by single companies at all. They
require a mental transformation by many actors together. You can't build a
democracy by being a dictator: it is very difficult to order people to think
for themselves. :-)
> 
> Yes, and sometimes the SemWeb community needs to remember that too re.
dictatorship as exemplified by RDF overeach and covert mandates:-)

I don't really see that.  There is not much of a dictatorship there as far
as I can see, unless you think as Plato did, that Philosophers should run
the affairs of the state.

The semweb community has done the theoretical work very well. What remains
are practical implementations that touch everybody, something that academia
is not interested in. Academia as Peter Williams said is interested in
looking at issues that are 10-20 years ahead of their time. Market based
implementations is what our role is. And it is we who have failed here.

We should stop discussing the theory and produce working, interoperable
structures. What is needed there are

 - appealing and viral use cases
 - test cases to make sure we interoperate
 - build recursively from the small to the more complex

To do this we don't need to convince Joe Web2.0 of anything. We just need to
make really good products that do something that no one else can do. 

Action speaks louder than words.

Henry






More information about the foaf-protocols mailing list