[foaf-protocols] Fwd: Re: WebID breakthrough - pure Javascript+Flash implementation

Melvin Carvalho melvincarvalho at gmail.com
Sat Aug 14 17:16:02 CEST 2010


On 13 August 2010 17:11, Bruno Harbulot <Bruno.Harbulot at manchester.ac.uk>wrote:

> Hi,
>
> You're absolutely right, RESTfulness matters for curl/Tabulator
> (essentially, non-browser user-agents). Does it matter to the general
> public using a browser for normal website usage? I'm not sure right now.
>
> It's a general problem regarding REST and authentication. It seems that
> some REST advocates claim both that (a) using cookies (including for
> authentication) makes a system not RESTful and (b) the virtues of REST
> are proven by the success of the WWW.
> Of course, that doesn't really work when you notice that most websites
> that require users to authenticate use forms nowadays.
>
> I'd be interested in a "WWW-Authenticate: Form" scheme or similar, and
> someone else started a draft on a "WWW-Authenticate: Cookie" spec. It
> just doesn't seem to get much interest, as far as I'm aware.
>
> I know it may sound a bit disappointing from a technical perspective,
> but REST isn't something that most users care about. Most people just
> want something that works when they're using a browser, and tend to be
> satisfied with the Facebook/Google/... account experience.
>
> I'm aware of the benefits of REST and RESTful authentication because
> I've been writing services targeted at both browsers and automated
> clients, but I reckon this still is a niche market.
>
> Again, if we don't make use of the keys with the WebID, the JS+Flash
> interface will look just like the existing OpenID choices at the moment
> (and that's not necessarily a bad thing). From there, I think it's going
> to be hard to convince most users to use a WebID rather than an OpenID
> (or even instead of their Google account, which most people might not
> even know is an OpenID provider).
>
> Sure, Linked Data goes further than the browser experience, but there
> are still a number of issues to address. I think it depends on what the
> target audiences are.
>

I think aligning to linked data principles is key.

OpenID doesnt (yet) have this ability, but can be bootstrapped.

I would suggest that without the prominence linked data element, WebID would
struggle to make it to rec status.

I think the target audience has to include the semantic web community, as
this is the first time we can start to effectively use UGC coupled with
LOD.  To my mind, that's a huge leap.


>
> Best wishes,
>
> Bruno.
>
>
> On 12/08/2010 21:23, Joe Presbrey wrote:
> > I am very surprised to hear this argument.
> >
> > AFAIK, the main technical problem with OpenID as an authentication
> > protocol in a Linked Data context is that it is not RESTful!  Using
> > Linked Data in meaningful ways goes well beyond the user in a Web
> > Browser experience.
> >
> > Linked Data w/ OpenID breaks HTTP completely when
> > [curl|rapper|Tabulator|insert data browser here] asks for RDF and it
> > redirects me to an authorization page at my IdP.  On the other hand,
> > WebID prompted SSL-authentication leading to correct HTTP status codes
> > indicate to any HTTP client written in our lifetime exactly what to
> > do.
> >
> > --
> > Joe Presbrey
> >
> > On Wed, Aug 11, 2010 at 8:11 AM, Bruno Harbulot
> > <Bruno.Harbulot at manchester.ac.uk>  wrote:
> >> My main point still is that, if we don't make suitable use of the public
> >> key but instead move away from using certificates, there's little point
> >> in developing WebID, we might as well try to extend OpenID with some
> >> semantic-web extensions.
> >>
> >>
> >> Best wishes,
> >>
> >> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100814/3b52e35f/attachment.htm 


More information about the foaf-protocols mailing list