Re: WebID for developers

Great stuff, good job capturing material on the Wiki.

You've given me plenty to look at too, thanks!

On 15 March 2012 22:35, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
> 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
>>
>



-- 
http://dannyayers.com

http://webbeep.it  - text to tones and back again

Received on Thursday, 15 March 2012 23:12:11 UTC