Re: WebID for developers

On 15 March 2012 13:45, Danny Ayers <danny.ayers@gmail.com> 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?
> ]]
>

Great use case!


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

I've made a list of authentication choices below.  Some are direct and some
are through a 3rd party.

http://www.w3.org/community/rww/wiki/Authentication

The essential idea of auth is to return an identifier, preferably a URI, to
build up long lived information about a user.

Some solutions may not require a long lived persistent URI, and use, for
example, the IP address.  This can be perpended with the dns: scheme.  For
example wikipedia does not require you to login, in order to edit, but you
can.

Generally you can delegate to a third party via facebook connect, oauth,
openid or browserid.

You can go direct via http basic/digest, or a cookie.  Ideally you would
then want to turn that local username into a global URI to achieve Web
Scale.

Perhaps have a look at the appbuilder that I made in JS that lets you sign
in with a number of methods:

http://appbuilder.data.fm/

Click on "Sign In" to see the choices.


>
> So where does WebID fit in this?
>

"The WebID Protocol" uses PKI to identify and authenticate a user URI.
During the setup of a TLS session you prove that you own a key pair which
is stored in a browser certificate.

The certificate also points to an HTTP URI that displays your public key.
In this way, the public key associated with the user, is connected to, say,
a homepage.  The advantage of doing this is that you now provide a web
scale identifier (your actual WebID) .


>      If I wanted to do everything locally, what are my options?
>

You need to setup your web server to accept HTTPS with client certificates,
and it should be able to pass down the credentials to the application.


>      Are there any 3rd parties I can delegate to? (hi Kingsley :)
>

Yes henry set up a nice service that can do all this for you at:

https://foafssl.org/srv/idp

The site asserts that the webid is valid, and you just then need to check
the signature.


>
> === 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?
>

Case 1: the (LAMP) system uses web scale identiefers (URIs).  That's good
you should be able to do a direct login() call.

Case 2: the (LAMP) system uses local identifiers.  You need to translate
this into a URI.  This can commonly be achieved by adding a column to the
user table.  Then the login phase can be changed to map your URI to a local
identifier.

Then you have the same permissions systems you used before but now things
are starting to scale.


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

We've started playing with this on data.fm and have a page about ACLs here

http://www.w3.org/community/rww/wiki/AccessControl

If it's helpful we can perhaps work through some real world examples?


> === 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?
>

Some browsers actually let you use your webid like a session, which is
quite nice.  On data.fm we actually use a cookie too.


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

Makes a lot of sense.  One good way to influence perceptions is with
compelling demos.  If we can make some of the apps that you're building
interop with other systems, hopefully we can prove the web philosophy of
the whole being greater than the sum of the parts.

The overriding principle here is that using URIs as identifiers (WebIDs) is
a great way to provide interop, and break down the walls in the social
web.  Using local identifers tends to lead to silos.  There's many ways to
authenticate an identifier, just pick the one that works best for you.

Hope that helps! :)


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