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

Re: WebID for developers

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 15 Mar 2012 15:50:32 +0100
Cc: public-rww@w3.org
Message-Id: <6B51FA36-CDE0-4C11-B358-1FFD271D27C3@bblfish.net>
To: Danny Ayers <danny.ayers@gmail.com>
I am just starting to write code to get the Play 2.0 framework be WebID 
enabled. Since they already have an OpenID and OAuth component, I'll 
soon be trying to think about this myself whilst implementing, which
is often the best way to explore the problem.

On 15 Mar 2012, at 13:45, Danny Ayers wrote:

> 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.
> 
> Cheers,
> Danny.
> 
> [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://dannyayers.com
> 
> http://webbeep.it  - text to tones and back again
> 

Social Web Architect
http://bblfish.net/
Received on Thursday, 15 March 2012 14:51:21 UTC

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