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

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. 

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.

>> 
>> 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.

> 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

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, ...

> 
>> 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?...)

> 
> 
>> 
>>> I continue to encourage you to separate the concept and virtues of WebID from a specific WebID solution that aligns with your personal world view etc..
>>> 
>>> In my world view, the simplest demonstration of WebID's value takes the following form:
>>> 
>>> 1. A resource is published to the Web
>>> 2. The resource is ACL protected
>>> 3. Existence of the resource is published via email, tweet, blog post etc..
>>> 4. A user tries to access the resource -- they fail or succeed subject to ACL membership
>>> 5. User requests access to resource by providing their WebID to resource owner -- this is also where signed email are useful since the WebID can be nipped from the senders signed email certificate.
>>> 
>>> In addition to the above, the resource acl document can itself have ACLs that enable a variety of users expand its ACL memebership thereby making an organic social network.
> 
> That's the interop outline above.
> 
>>> 
>>> 
>>> -- 
>>> 
>>> 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 19:57:14 UTC