- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 25 Sep 2012 22:26:17 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid@w3.org
On 25 Sep 2012, at 22:11, Kingsley Idehen <kidehen@openlinksw.com> wrote: > 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. How does a robot do that? > 6. Request addition of your WebID to the ACL for a protected resource from other participants this the interop. How does a robot do that? This is the issues that need to be worked on. > >> >> 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. WebID does not have a lot of deployment either. Perhaps due to lack of methods of getting things to work consistently. > >> >>>> 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. It works with HTTP. There are HTTP error codes 400, etc to explain when things don't work. Perhaps those would be enough.... We have not yet really looked at all the possibilities here. > >> >>> 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. Euh, we have not tried it yet. We have a few initial ideas on how to do it, but it needs feedback from the community. I think we may have initially over-engineered the solution. Anyway, if you don't want automatic tools to verify WebID's then we'll have to keep being subjective. And for the moment for me my-profile.eu does it for me. When it works it is the easiest for a human to use. Since we don't have standards to know when system for robots are easy to use, I can't tell if any other system is working well. > >> >> 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. I am . I think it is going to be extreemly important to know why access failed. When you go to a web site and you can't login the best web sites give you a human explanation. We are dealing with robots now, so we need the equivalent for robots. Otherwise you'll just have bad customer experience. TLS gives you some error codes, but nowhere near to close what we need for good user experience. And here I am speaking about Robot user experience too. Also the error codes are not fined grained enough to help explain that your WebID could not be dereferenced or such ( there are 4 error codes perhaps ) So I'd say this is close to priority number 1. Henry > > [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 > > > > > Social Web Architect http://bblfish.net/
Received on Tuesday, 25 September 2012 20:26:52 UTC