[foaf-protocols] WebID talk at W3C

[Melvin Carvalho]

On 24 August 2010 18:16, Seth Russell <russell.seth at gmail.com> wrote:

> On Tue, Aug 24, 2010 at 1:56 AM, Stéphane Corlosquet <
> scorlosquet at gmail.com> wrote:
>
>>
>> On Tue, Aug 24, 2010 at 2:37 AM, Manu Sporny <msporny at digitalbazaar.com>wrote:
>>
>>> The slides that I've prepared for the presentation are here:
>>>
>>> http://payswarm.com/slides/webid/
>>
>>
>> from http://payswarm.com/slides/webid/#(5)<http://payswarm.com/slides/webid/#%285%29>
>>
>> > "OpenID isn't quite decentralized - requires the identity provider to be
>> available at all times"
>>
>> This should be reworded. WebID suffers from the same shortcoming: if your
>> WebID URI does not dereference or if your WebID Profile document is down,
>> you cannot log in. That's something the multiple SAN URIs could solve:
>> http://github.com/msporny/webid-spec/issues#issue/2
>>
>> Steph.
>>
>>
> Can't a web site use the WebID to allow a client to "log in" whether the
> "Profile document" is online or not?  Sure the site cannot verify the
> document, but that verification need not be required for each log in.   Have
> we required the verification on each login?  Why would we do that?   Why
> would we purposefully make our WebID less reliable?  What am i missing here?


The first time a Verification Agent checks the certificate / FOAF it will
need to dereference the FOAF.

In practice, subsequent attempts may take advantage of web architecture /
caching, or use, for example,  a cookie for convenience.


>
>
> Seth Russell
> Podcasting: tagtalking.net
> Facebook ing: facebook.com/russell.seth
> Twitter ing: twitter.com/SethRussell
> Blogging: fastblogit.com/seth/
> Catalog selling: www.speaktomecatalog.com
> Google profile: google.com/profiles/russell.seth
>
>
> _______________________________________________
> 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/20100824/20081986/attachment-0001.htm