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

Re: a totally minimal RDFa doc, please

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 14 Apr 2011 14:31:27 -0400
Message-ID: <4DA73D7F.6020502@openlinksw.com>
To: Henry Story <henry.story@bblfish.net>
CC: Coralie Mercier <coralie@w3.org>, WebID XG <public-xg-webid@w3.org>
> On 14 Apr 2011, at 19:31, Kingsley Idehen wrote:
>
>>> On 14 Apr 2011, at 18:03, Kingsley Idehen wrote:
>>>
>>>>> On 14 Apr 2011, at 17:41, Kingsley Idehen wrote:
>>>>>
>>>>>>> (I generated the page from the second tab of http://x509.me
>>>>>>> The test a certificate option. My cert was generated of the first page (optional). My cert had a SAN pointing to a blank page to start with. Press the test button on the second tab. It fails as it was a blank page and spits out the rdfa required for it to pass. Cut, copy, paste.)
>>>>>>>
>>>>>> I just tested the service above.
>>>>>>
>>>>>> Results:
>>>>>>
>>>>>> 1. HTTP scheme WebIDs - Pass
>>>>>> 2. Non HTTP scheme WebIDs - Fail .
>>>>>>
>>>>>> WebID is not about HTTP scheme WebIDs, solely. Courtesy of WWW ubiquity, HTTP scheme WebIDs are a very cost-effective *option*. Important downside: they are unintuitive.
>>> [WebId's are no less unintuitive that webfinger, not when they are hidden in a certificate. In both cases point an click a cert selector and you are done. But let's discuss that another time.]
>> My key point (very very important): verification shouldn't be scoped to HTTP scheme based WebIDs.
> Nobody says it was. And I was the first to point out a long time ago on the webid mailing list that it need not be, and to develop the logical basis for why this is the case.  It is related to the sense and reference distinction which is core to all of logic as I point out in the FAQ
>
>    http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_with_FOAF.2BSSL.3F
>
>> If a service takes that position it has to make it crystal clear. Failure to do this simply reeks of coercsion.
> How could one coerce logical truths?

On planet earth, it pretty much happens everyday :-)

>> As I've stated already, HTTP scheme URIs are cost-effective, naturally, due to WWW ubiquity. That still doesn't justify specificity when dealing with WebID.
> You misunderstand what I am suggesting we do. I am raising pragmatic issues of interoperability of implementations and test based development. Most webid implementations are using http and https uris so lets start testing and specifying those clearly. Then we move on to the next. If we stay focused this could be done thoroughly in a month.  That gives us ample time to deal with all the other protocols.
>> Of course, we can (right now) decide that WebID is about HTTP scheme URIs as WebIDs, no problem, but lets be crystal clear about these matters right now.
> Again nobody has decided and has thought of deciding anything of the sort. You are tilting at windmills here Kinglsey :-)

I think you once suggested better error handling for anything that 
claims to be a test suite, right?

It would also be nice if developers did the following: made URI scheme 
specificity clear e.g. simple notice at point of entry.

Either one of the above would save folks like me (with many certs and 
uri scheme combos) from burning time.

I think that's simple and pragmatic, right? :-)


Kingsley
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Thursday, 14 April 2011 18:31:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC