[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