W3C home > Mailing lists > Public > public-webid@w3.org > September 2012

Re: Some WebID questions - was: [dane] Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 25 Sep 2012 16:11:05 -0400
Message-ID: <50620FD9.3020706@openlinksw.com>
To: Henry Story <henry.story@bblfish.net>
CC: public-webid@w3.org
On 9/25/12 3:56 PM, Henry Story wrote:
> On 25 Sep 2012, at 21:34, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 9/25/12 3:24 PM, Henry Story wrote:
>>> Can we shift to this new title? I forgot to change it when forwarding the mail to this list.
>>>
>>> On 25 Sep 2012, at 21:16, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>
>>>> On 9/25/12 2:44 PM, Henry Story wrote:
>>>>>    I am just ccing Andrei, because Ben (http://research.google.com/pubs/author9639.html  ) - has found a bug inhttps://my-profile.eu/  . (see below) My guess is that Ben logged in with a certificate that is not WebID enabled. So that's a good extra test case to add. Of course for people like Ben, the failure of having a Logout button on chrome is going to add to that inconvenience - because having logged in with a certificate that may not be signed by a CA my-profile.eu knows about, he won't be able to change his certificate later after having made a new one.
>>>> Ben,
>>>>
>>>> Wondering if you evaluated WebID using any other services or scenarios? Your feedback would be much appreciated.
>>>>
>>>> Henry: I keep on telling you, one implementation doesn't canonically reflect WebID.
>>> I don't think I was serious in saying the my-profile.eu is canonical. But it does show what a good user experience is (when it works)
>> For you, but that isn't the critical point here. WebID is not made or broken (solely) by application UI. Just like the Web isn't made or broken (soley) by application UI.
> I completely agree, that WebID is not just a client side thing. It will be big between robots communicating. The problem is that when explaining things initially to humans, they need to see it working.

That's the mistake many of us made re. Linked Data.

Here's a simple demo for any end-user that can make a document and save 
it to a directory:

1. Create a turtle document  -- this this case fill in the placeholders 
of a template doc (the most important aspect of this effort)
2. Publish doc to Web -- you achieve this not via Apache but by copying 
the local file to a folder provided by the likes of Dropbox, SkyDrive, 
S3 (which accept and grok mime type: text/plain)
3. Generate a Certificate using tools provided by OS -- Windows, Mac OS 
X, and Linux all have native Cert. generators
4. Copy the following from the generated cert: Public Key, Fingerprint 
(SHA-1 or MD5), and then paste into local document created in step 1 or 
paste directly to published document -- if using local doc, just 
republish after adding the components
5. Use an WebID authentication tool to verify that your Certificate and 
its WebID are indeed usable
6. Request addition of your WebID to the ACL for a protected resource 
from other participants this the interop.

>
> In fact all the demonstration cases for read-write-web use curl on this page
>    https://dvcs.w3.org/hg/read-write-web/
>
>
>> That's the problem with Links, they are powerful in ways that aren't always dependent on the conventional application interaction pattern.
>>
>> A WebID is setting the condition(s) for URI de-reference.
>
>
>>>> As you can imagine, Ben is time challenged, if he plays with a solution that's pitched as canonical its natural for him to draw blanket conclusions.
>>> Yes, the best way to do that would be to work on a test suite, that would cover all these cases.
>>> I put a few proposals for this up a year ago or so:
>>>
>>>    http://www.w3.org/2005/Incubator/webid/wiki/Test_Suite
>> Not a conventional branch-coverage style of testsuite, that too is just another one of those patterns that doesn't totally gel with the conditions that determine URI de-reference.
> I am not sure what you mean by a conventional branch coverage.  I am not sure why we could not get a test suite to work properly.

If that worked, you would have entries for all implementers of WebID at 
this point. The issue of testsuite driven interop would be closed etc..

The testsuite you refer to is an example of code branch coverage in my 
lingo.

>
>>> Would you be prepared to commit on implementing the pieces necessary in your products to get this going?
>> I have no idea what the statement above means. WebID has been long implemented across our product portfolio. For whatever reasons, that remains quite unclear to you.
> The point is not to say that you have or have not implemented webid. It is to be able to point to a suite that can verify that for your implementation and indeed any other implementation.

Again, that doesn't work. Never has. I've been through many iterations 
of this kind of thing with SQL, ODBC, JDBC, OLE-DB, ADO.NET, IIOP, HTTP 
etc.. its never worked. What works is a practical use case that hones 
into the heart of the matter. In this case, its a conditional URI 
de-reference.

>
>> Are you asking for us to make a testsuite?
> No. The idea - which may perhaps not have been explained carefully enough here
>    
>    http://www.w3.org/2005/Incubator/webid/wiki/Test_Suite
>
> is that a WebID resource that cannot authenticate the client respond in a way that make clear why it could not authenticate the user. Perhaps a 40x client error with an RDF document explaining perhaps one of the following:
>    - there was not idx, and the CA was not known
>    - the WebID idx could not be verified because
>      + idx could not be dereferenced
>      + idx does not contain correct public key association
>      ...
>    - the resource is not allowed for the user

Okay, so this is more to do with response clarity that works for humans 
and machines. That said, it hasn't generated the results we seek re. 
active interop from this WebID and RWW communities, so we need to try 
something else.

>
> If we can make this machine readable then software agents can be built
> to access any webid resource and see if it responds correctly to a broken
> or WebID certificate, ...

Later.

>
>>> We certainly need to simplify the test suite. But with this we could add tests for all the types of problems we come across to an open source software stack. The we could have objective up to date tests on servers that properly impelement WebID.
>> An object way of testing WebID is by having a publisher share a resource with a ACL list that leverages WebID for identity authentication. You can have many resource publishers and consumers perform these tests.
> yes, but the robots ( or human testers ) need to know why they were refused access ( no access allowed, webid not verified?...)

Yes, but they have to actually try first. I haven't seen any messages 
posted here, or anywhere else for that matter,  where folks are seeking 
clarity about failed resource access or URI-dereference.

[SNIP]

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Tuesday, 25 September 2012 20:11:29 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:40:59 UTC