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

Melvin Carvalho melvincarvalho at gmail.com
Wed Mar 23 15:14:29 CET 2011

On 23 March 2011 08:58, peter williams <home_pw at msn.com> wrote:
> So how can we engineer a trivial to execute means of populating a million
> blog sites with a foaf card?

iivejournal blogs have foaf, that's at least 10 million, then there's
status.net microblog, and hi5 is probably another 50 million

> 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
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list