[foaf-protocols] webid-linked claim verification?
kidehen at openlinksw.com
Thu Aug 26 21:24:52 CEST 2010
On 8/26/10 3:09 PM, Seth Russell wrote:
> On Thu, Aug 26, 2010 at 11:53 AM, Kingsley Idehen
> <kidehen at openlinksw.com <mailto:kidehen at openlinksw.com>> wrote:
> On 8/26/10 11:25 AM, Seth Russell 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.
> Yes, but wouldn't it be even better if you sent the message via
> their preferred channel? Today, we have email, Twitter DMs,
> LinkedIn, Jabber, Skype etc.. to name a few.
> Yes, totally, totally, but I don't grock the "you" part, kemosabe!
> I want to just send the message to the library and *it* will send the
> message in the client's preferred protocol and address.
Okay, you call a service (built with a library) or actual library that
has said functionality :-)
> I don't know how to do all of that comminicating and keep my
> programming up to date as this system evolves rapidly over time. It
> would be impractical to suppose that anybody will, except perhaps the
> largest enterprises who can afford to hire dozens of programmers. But
> you developers of libraries can compete for who can provide the best
> communication channel for us.
We are really gunning for the same thing. A service or library would
deliver this functionality.
>> I want all that discerning to be out of my sight and concern
>> and totally under the client's control.
> So the client prefers Skype at a certain point in the day, week,
> month etc.. And this is when you want to communicate, what
> happens? They've indicated thir preferred mechanism, but its in
> their data space somewhere (but discoverable via the graph that is
> the data space).
>> 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
> This is just one of those things that works best via a
> deliverable. When I am ready I'll just show it. This sometimes
> works better re. different routes to the same destination :-)
> Hmmm.... i can hardly wait ...
For me it will be a service rather than a PHP library re. deliverable.
Naturally, it will be part of ODS (which does expose its functionality
for RESTful HTTP based interaction). Anyway, stay tuned !
>> Seth Russell
>> Podcasting: tagtalking.net <http://tagtalking.net>
>> Facebook ing: 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
>> Google profile: 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
>>> Seth Russell
>>> Podcasting: tagtalking.net <http://tagtalking.net>
>>> Facebook ing: facebook.com/russell.seth
>>> Twitter ing: twitter.com/SethRussell
>>> Blogging: fastblogit.com/seth/ <http://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 <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
>>> 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
>>> [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
>>> ... 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
>>> 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
>>> provider. But also to counter some of the concerns I've
>>> seen raised
>>> about self-asserted ID. Is there anything out there like
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> <mailto:foaf-protocols at lists.foaf-project.org>
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org <mailto:foaf-protocols at lists.foaf-project.org>
>> Kingsley Idehen
>> President& CEO
>> OpenLink Software
>> 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>
> Kingsley Idehen
> President& CEO
> OpenLink Software
> Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca: kidehen
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols