[foaf-protocols] webid-linked claim verification?
Kingsley Idehen
kidehen at openlinksw.com
Thu Aug 26 20:57:59 CEST 2010
On 8/26/10 11:35 AM, Seth Russell wrote:
> In other words. I want a library with the following 4 functions ...
>
> $id = signup()
> $id = signin()
> sendMessage ($id, $message)
> getMessage ($id, $message)
>
> Seth Russell
> Podcasting: tagtalking.net <http://tagtalking.net>
> Facebook ing: facebook.com/russell.seth <http://facebook.com/russell.seth>
> Twitter ing: twitter.com/SethRussell <http://twitter.com/SethRussell>
> Blogging: fastblogit.com/seth/ <http://fastblogit.com/seth/>
> Catalog selling: www.speaktomecatalog.com
> <http://www.speaktomecatalog.com>
> Google profile: google.com/profiles/russell.seth
> <http://google.com/profiles/russell.seth>
Funny reading the above, your mail signature carries the clues to how
$message ends up riding the optimal channel :-)
Just need "preferred contact mechanism" (with a temporal aspect) in a
vocabulary thats aligned to FOAF.
Sorta like this: http://crschmidt.net/foaf/menow/menow.rdf .
Kingsley
>
>
> On Thu, Aug 26, 2010 at 8:25 AM, Seth Russell <russell.seth at gmail.com
> <mailto:russell.seth at gmail.com>> wrote:
>
> Well, actually, as a website owner, i don't want to be discerning
> anything. All i really want to do is just send messages to my
> clients. I want all that discerning to be out of my sight and
> concern and totally under the client's control. That is my real
> point here. And, when you think about it, if the libraries take
> the approach of factoring all that discerning into the control of
> the client and just let the website send (and perhaps recieve)
> messages from the client, then all that magic we want can evolve
> in the libraries and my web development code can be left alone.
> Me thinks this is a path to a faster evolution for all those
> wonderful WebID benefits that are being touted.
>
>
> Seth Russell
> Podcasting: tagtalking.net <http://tagtalking.net>
> Facebook ing: facebook.com/russell.seth
> <http://facebook.com/russell.seth>
> Twitter ing: twitter.com/SethRussell <http://twitter.com/SethRussell>
> Blogging: fastblogit.com/seth/ <http://fastblogit.com/seth/>
> Catalog selling: www.speaktomecatalog.com
> <http://www.speaktomecatalog.com>
> Google profile: google.com/profiles/russell.seth
> <http://google.com/profiles/russell.seth>
>
>
> On Thu, Aug 26, 2010 at 8:01 AM, Kingsley Idehen
> <kidehen at openlinksw.com <mailto:kidehen at openlinksw.com>> wrote:
>
> On 8/26/10 8:31 AM, Seth Russell wrote:
>> Dan Brickley said: If we assume the possibility of a simple
>> Web app that allows users to demonstrate simultaneous control
>> over multiple accounts, the natural next question is re what
>> it does with that info.
>>
>> Well perhaps answering that question: one of the biggest use
>> cases for identity on the web is where some website, say a
>> shopping site, wants to know who a person is ** so that they
>> can communicate with that person **. All we, the website
>> owners, really want is a open source library given to us with
>> a function to call which would return some identity string to
>> store in our local database. When we need to send a message
>> back to the person all we really want to do is to send a
>> message referencing that identity string. The library takes
>> it from there, and we, the site owners, are no longer
>> concerned with details like verifying email addresses,
>> twitter accounts, or even in which protocol the client
>> prefers to get their messages.
>>
>> I really appreciate Dan's call for a verification of claims
>> and hope that it will inevitably dove tail into that library
>> i so desperately need but can't write myself.
>
> Not only can you figure out how to communicate with them. You
> can discern their preferred communication mechanism. You could
> even discern their location and bike something over to them or
> keep the store open a little longer (clicks and mortar
> scenario with some GoodRelations Linked Data sprinkled in).
>
> Kingsley
>
>>
>> Seth Russell
>> Podcasting: tagtalking.net <http://tagtalking.net>
>> Facebook ing: facebook.com/russell.seth
>> <http://facebook.com/russell.seth>
>> Twitter ing: twitter.com/SethRussell
>> <http://twitter.com/SethRussell>
>> Blogging: fastblogit.com/seth/ <http://fastblogit.com/seth/>
>> Catalog selling: www.speaktomecatalog.com
>> <http://www.speaktomecatalog.com>
>> Google profile: google.com/profiles/russell.seth
>> <http://google.com/profiles/russell.seth>
>>
>>
>> On Thu, Aug 26, 2010 at 12:47 AM, Dan Brickley
>> <danbri at danbri.org <mailto:danbri at danbri.org>> wrote:
>>
>> Hi folks
>>
>> Has anyone here built a webapp that shows verification of
>> simple
>> identity-relevant claims? This idea is not tightly
>> coupled to WebID
>> but would help ground WebIDs (or equally self-hosted
>> OpenIDs) in other
>> identifying information.
>>
>> e.g. 1.) you go along, log in with a webid cert, and
>> select "verify an
>> email address"; it sends you some generated token by
>> email, with a
>> URL; you get that mail, follow the link, log in again
>> with webid if
>> needed [eg. the mail might arrive tommorrow], ... after
>> which you've
>> established some evidence that whoever controls that
>> webid also
>> controls (for now) that mailbox.
>>
>> e.g. 2.) you go along, log in with a webid cert, and
>> select "verify a
>> Web account", and choose a provider from a list of
>> service providers
>> who offer OpenID, OAuth and/or proprietary API ways of
>> allowing
>> someone to demonstrate control over an account. For
>> OpenID you should
>> also have the ability to type in an arbitrary
>> OpenID-enabled URL. So
>> here you might verify that you control
>> http://twitter.com/example
>> [this would use OAuth], or a Facebook account.
>>
>> e.g. 3.) or you login with webid again, and select
>> "verify a Chat
>> account"; selecting from MSN, Yahoo, AIM, or Jabber/XMPP.
>> Actually
>> these things are increasingly linked to general Web
>> profiles, but at
>> least Jabber/XMPP would be particularly interesting. So
>> you'd type in
>> your chat address, let's say johnsmith at gmail.com
>> <mailto:johnsmith at gmail.com> for a Google Talk
>> one, but these can also be self-hosted XMPP servers eg.
>> danbri at foaf.tv <mailto:danbri at foaf.tv>. The service would
>> send a roster join request to that
>> user, and if accepted, could send a click-to-verify link
>> much as with
>> the email example.
>>
>> e.g. 4.) More stuff! There are no natural limits to the
>> kinds of
>> claims that could be verified, or the methods applied.
>> This is the
>> charm and the burden of the Semantic Web; it's
>> completely general.
>> But fact checking is hard, so there is value in picking
>> off the more
>> mechanisable pieces; mobile phone / SMS numbers could be
>> a natural
>> next step.
>>
>> There are a lot of 'claim graph analytics' you can do
>> with this sort
>> of data, especially when linked with other social Web
>> data (quite
>> naturally in named graphs, when managed in SPARQL). This
>> is the same
>> kind of machinery offered by
>> http://code.google.com/apis/socialgraph/
>> ... although SGAPI deals more with public crawlable
>> assertions. If we
>> assume the possibility of a simple Web app that allows
>> users to
>> demonstrate simultaneous control over multiple accounts,
>> the natural
>> next question is re what it does with that info. Some of
>> it could be
>> simply published in public (signed, date stamped etc.) or
>> made
>> available over some public lookup API.
>>
>> eg. it could just emit a 'verified claims' file with
>> simple statements, ...
>> <http://example.com/johnsmith#me> a :Person; :account
>> <http://twitter.example.com/johnsmith>; :account
>> <http://facebook.example.com/jsmith/> ...
>>
>> Such info could be used as a grounding for more trust,
>> eg. my blog
>> comments system could allow webid-based commenting, and
>> auto-accept
>> posts that came from people whose twitter or facebook IDs
>> I know, even
>> if I've not seen their webid before. Some such tool seems
>> to me worth
>> building, both to show that these service activities will
>> still exist
>> in a WebID world, they're just not core duties of an identity
>> provider. But also to counter some of the concerns I've
>> seen raised
>> about self-asserted ID. Is there anything out there like this
>> currently?
>>
>> cheers,
>>
>> Dan
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> <mailto:foaf-protocols at lists.foaf-project.org>
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>>
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org <mailto:foaf-protocols at lists.foaf-project.org>
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> President& CEO
> OpenLink Software
> Web:http://www.openlinksw.com
> Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca: kidehen
>
>
>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> <mailto:foaf-protocols at lists.foaf-project.org>
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
>
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100826/5a9dfd5d/attachment-0001.htm
More information about the foaf-protocols
mailing list