- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 26 Sep 2012 00:19:45 +0200
- To: Ben Laurie <benl@google.com>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-webid@w3.org" <public-webid@w3.org>, Andrei Sambra <andrei@fcns.eu>
On 25 Sep 2012, at 23:31, Ben Laurie <benl@google.com> wrote: > On 25 September 2012 20: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. 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. >> >> 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. > > Gah! What does this have to do with WebID? If I substitue "magic pixie > dust" for "WebID" in the above, well, I have a fantastic example of > how magic pixie dust secures the web. Great. Now what? > > OK, I guess there's one nugget in there: apparently magic pixie dust > can be nipped from unauthenticated email I sent. > > I'm not feeling very enlightened. I think Kingsley was pointing out that an important use case of WebID that talking only about web browsers can hide, is for agents exchanging data on the Web. Think about an agent trying to access a resource on a remote web server. With WebID the agent can use his client certificate to authenticate as he accesses the resource, without having to search for a login form to fill out. It is built into the transport layer so is very efficient too. You will find something like the example of this kind of use of WebID in the descriptions of how to use the read-write-web server here https://dvcs.w3.org/hg/read-write-web/ or in code the following use case gives an idea of how a robot can create an identity using only HTTP, add an ACL which then restricts access to a resources to a particular webid, etc... https://dvcs.w3.org/hg/read-write-web/file/258d2757ef3d/src/test/scala/auth/CreateWebIDSpec.scala#l122 This type of work is important in Linked Data spaces where linked data crawlers are moving from one host to another following links (see http://linkeddata.org/ ) But even there user interface issues are important. It is important for the client to know why the server did not accept the authentication. We can use HTTP codes for this, but we could complement them with further information sent back in the response body in addition to a the response codes. So for example looking at http://en.wikipedia.org/wiki/List_of_HTTP_status_codes the server could return 401 Unauthorized -- here the server could say why? did the webid verification process fail? 403 Forbidden --- perhaps the response could say what foaf:Group had access 495 Cert Error (Nginx) - what kind of error? No trusted CA? No WebID ? 496 No Cert (Nginx) - ok that says enough by itself. No WebID auth if no cert was sent We could then have a very specific test page which when authentication was successful returned 200 + an Echo of the certificate sent perhaps But we still need to work this out more here. These are just things we could do to improve the data sent and so could be used to improve human oriented UIs. Henry Social Web Architect http://bblfish.net/
Received on Tuesday, 25 September 2012 22:20:19 UTC