[foaf-protocols] webid-linked claim verification?

Seth Russell russell.seth at gmail.com
Thu Aug 26 17:35:15 CEST 2010


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
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


On Thu, Aug 26, 2010 at 8:25 AM, Seth Russell <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
> 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
>
>
> On Thu, Aug 26, 2010 at 8:01 AM, Kingsley Idehen <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
>> 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
>>
>>
>> On Thu, Aug 26, 2010 at 12:47 AM, Dan Brickley <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 for a Google Talk
>>> one, but these can also be self-hosted XMPP servers eg.
>>> 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
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>>
>>
>>
>> _______________________________________________
>> foaf-protocols mailing listfoaf-protocols at lists.foaf-project.orghttp://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
>> 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/20100826/6de06fa4/attachment-0001.htm 


More information about the foaf-protocols mailing list