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

On 9/25/12 4:26 PM, Henry Story wrote:
> 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?

I really didn't outline the above with a robot in mind. Do end-users 
know what HTTP bots are, typically?

Anyway, if you want a bot map, then its must about using curl to move 
the resource re. publication. Ditto use of curl to attempt resource access.

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

Send a signed email. And if that isn't possible send a Semantic Pingback 
notice. Send a Tweet, Facebook, or LinkedIn post via their respective 
REST endpoints etc..

Please note, that bots aren't the the bootstrap basis I have in mind. 
What I am outlining to you is dead simple and it works for end-users.

You could also benefit from signing your emails with a cert. that has 
your WebID in its SAN :-)

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

I think WebID is a little more extensively used than you might imagine. 
I told you about a few years ago that 30K customers and evaluators of 
our products and services already have WebIDs :-)


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

You are missing my point. The codes aren't the issue. The entire 
testuite approach isn't how you bootstrap something like WebID. The 
pattern has never worked and it won't start 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.

Again, you are not getting my point. You have a pathway kinds hardwired 
in your mind, and as a result you are not really grasping my fundamental 
point re. bootstrap. If you did, you would have been signing your emails 
by now.

>   We have a few initial ideas on how to do it, but it needs feedback from the community.

That's your view point, not mine.

>   I think we may have initially over-engineered the solution.

Maybe, that's why I we YouID/NetID protocol options (within or WebID 
implementation) that incorporate the more "cut and paste" friendly cert. 
fingerprints into the mix.

>
> Anyway, if you don't want automatic tools to verify WebID's then we'll have to keep being subjective.
If you feel that's the only alternative fine. I am only interested in 
actual use of WebID. I know how many WebID's we'll have online since we 
simply need to notify our customers about the little gift we've made for 
them, so as far as I am concerned the bootstrap path is crystal clear.

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

That's fine, I am not that bothered about your individual preferences. I 
am only concerned about your singling out a specific project as 
canonical while also trying to foster a community. No more, no less. And 
for the record, I actually like my-profile.eu a lot, just as I would any 
WebID implementation from any other member of this community.


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

You are missing my point.

I think the best thing here is for you to continue doing whatever works 
for you. I simply urge you to be cognizant of the implications that 
arise from pushing one effort as canonical based on your personal 
preferences. That's all.


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

You one individual.


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

I am actually not focused on robots. I am interested in WebID for the 
masses of end-users that seek to regain control over their identities, 
privacy etc.. I am not interested in premature optimization, it doesn't 
work for bootstraps.

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

For you, not the rest of the community.


Kingsley
>
> 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/
>
>
>


-- 

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