W3C home > Mailing lists > Public > public-rww@w3.org > March 2012

WebID for developers

From: Danny Ayers <danny.ayers@gmail.com>
Date: Thu, 15 Mar 2012 13:45:59 +0100
Message-ID: <CAM=Pv=T9NjYhgKeYQqpzxn813p1dbH33Db99uft5cHKYzDgxAQ@mail.gmail.com>
To: public-rww@w3.org
I spent this morning catching up with the docs and it seem to me
there's something missing. Something to directly answer a scenario
like this:
I'm a developer building a new blogging service.
I want to allow three kinds of access to the service: Admin (someone
who can manage the service), User ( post to a blog) and Public (anyone
can comment on posts).

      I've heard WebID is a Good Idea, but how do I use this in my application?
(Requirements like this are pretty common in the current generation of
Web application/service/sites, but a blogging service with those
particular controls is an uncomplicated example)

As it happens I am (more or less) that developer. For a piece of app
I'm working [1] on I want this kind of facility. Over the past few
weeks I've been reading and asking around the alternatives. Two
guiding principles: 1.make it easy for the end user 2. wherever
possible follow good practices. Three aspects stand out:
authentication, authorization and sessions.

=== Authentication ===
Generally we're talking about having a username-password pair or
something similar that are known by the user and the service but
no-one else.
The list of possible approaches is pretty long. First question is
whether to handle this locally or delegate it to another service.
Check the list for everyauth [2] - there are loads of existing
services that can be used. But for doing things locally, at the top of
the list are:
* HTTP Basic - simple, but insecure
* HTTP Digest - more secure, but problematic for the user (e.g.
browser must be closed to log out)
Asking around (on G+) the consensus seemed to be that Digest was more
trouble than it was worth, and that probably the best approach was:
* Basic over HTTPS - apparently combines the best features of the above.

So where does WebID fit in this?
      If I wanted to do everything locally, what are my options?
      Are there any 3rd parties I can delegate to? (hi Kingsley :)

=== Authorization ===
Once we have some kind of shared secret, the question become one of
how to use this to control access to resources. Assuming a setup like
the LAMP stack, the auth data might be stored in something like LDAP
or more probably a DB table. Some secured code will compare requests
with what's in the table, maybe responding with a redirect where the
user hasn't the right credentials.
But if we're talking about WebID, the data about the user will be in RDF.
      So would a triplestore really be necessary for management of
WebID-based authorization?
      How do I do it on LAMP?

Ok, I personally am working against triplestores anyhow, so for me
that particular question isn't so relevant. But it still isn't plain
sailing, there's a bit of a conflict between the semwebby
everything-linked mindset and having resources protected by an ACL.
How do you provide granular access to graphs where some of the data
will be private? With my little app I'm trying to do as much of the
data access (R/W) as possible using SPARQL 1.1. When you're trying to
provide access with granular control, it starts to look rather
difficult. The reading of data can be contained by using a lot of
smallish graphs with individual access control, and using (maybe
temporary) CONSTRUCTed graphs against which to fire the actual
queries. But when it comes to writing...well I haven't quite figured
that bit out yet. (In practice I'm assuming that the complexity of
access wiring needed will be a direct function of the complexity of
the ACL, so for something like the blogging scenario won't actually be
too bad - i.e. it isn't necessary to solve for the general case).

=== Sessions ===
Ok, this is a fly in the ointment. There's conflict between best
practices and usability (with the current generation of browsers at
least). An awful lot of sites/services out there use the idea that you
login in and the server remembers you are logged in until you log out.
Very user-friendly. But they don't follow the RESTful approach of
sending complete messages (including auth) for each request. Typically
cookies interact with server state. While I've been looking into this
I've seen no end of claims of "RESTful authentication" that are
actually just cookie based setups that happen to use systematic naming
schemes for URIs. (And a RESTful API seems to be defined as anything
supports PUT and DELETE, but that's another story...).

      So how can WebID be used in a system that follows best
practices, while still being user-friendly?

Although a purist answer would be nice here, perhaps more useful for
adoption would be a pragmatic one which starts with WebID but then
leads to cookie-based sessions.

I started looking into this because I wanted to do auth with 1. make
it easy for the end user 2. wherever possible follow good practices,
but really what I'm asking here is about 3. make it easy for the
site/service developer. Personally one reason I was looking at other
techniques before WebID was because I'm frightened of anything
involving signing. I do see how WebID ties nicely in with the whole
practical linked data Web etc etc notion which I'm enthusiastic about
- but one look at those message path diagrams and I'm scared! (I just
discovered some node.js code [3] so that should break the ice for the
app I'm working on).

One of the big obstacles to adoption of semweb tech is the perception
that it's complicated (thanks RDF/XML!). Reasonably secure
authentication, authorization etc. does have an unavoidable level of
complexity no matter how it's done, but right now I think it'd be fair
to say WebID looks a lot harder than it is.


[1] https://plus.google.com/b/102910670341143019851/102910670341143019851/posts/2f2Duq4LDzu
[2] https://github.com/bnoguchi/everyauth#readme
[3] http://magnetik.github.com/node-webid-report/


http://webbeep.it  - text to tones and back again
Received on Thursday, 15 March 2012 12:46:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:10:25 UTC