W3C home > Mailing lists > Public > public-xg-webid@w3.org > May 2011

RE: webid trust model, one or multiple?

From: peter williams <home_pw@msn.com>
Date: Mon, 2 May 2011 14:34:49 -0700
Message-ID: <SNT143-ds523175E4161D52706AE0E929F0@phx.gbl>
To: "'Melvin Carvalho'" <melvincarvalho@gmail.com>
CC: "'Kingsley Idehen'" <kidehen@openlinksw.com>, <public-xg-webid@w3.org>
So where do we fit into the trust space?

Lets assume we are trying to fit into both legacy and future - which the
right balance. Assume we are not ultra-religious, about proper architecture.
Assume utility is most important.

We know even by openid 2's appearance, that the live journal notion (openid
1) had fallen by the wayside. The FOAF basis of openid 1 was even further
back in time, and even more irrelevant. The netscape practice from 1996,
before ldap era at Netscape, of having personal home pages on
http://netscape.com/~jeffw died a very, very long time ago. 

We know that the core political agreement in openid space - between openid
and XRI - had two goals BOTH of which fell by the wayside post openid2.
First, the use of an XRI record as user-centric intermediary between IDP(s)
and consumer sites died. Second, also died the use of a hierarchy of signed
XRD files for multiple namespaces - which competed with a hierarchy of
signed RR files known as DNSsec (preferred by US govt, and which ties to be
fair into IPv6 and IPsec). The latter -- in the XRI/XRD case - allowed for
poly-archical relationship models - competing with triples and RDF and
Sparql (in many ways). The well known war of URI vs XRI was actually a

Anyways, ALL of that stuff above has fallen by the wayside. None of it has
relevance. Henry was wrong to state in the paper that openid requires a user
to type a URI (whereas webid doesn’t). Openid in practice has not required
typing URIs in years, and the number of folks using that legacy mode is next
to zero. This compares with a billion Google users (using nascar-mode
openid2.) Microsoft's ACS bridge doesn’t even bother enabling legacy URI
interoperability (so it wont talk to the wordpress IDPs, or at least its
hard to configure in the default admin UI).

Now, when I used to talk to John Bradley who is a fair minded engineering
with solid protocol, identity, and trust [framework] ideas, I came away with
the impression that he and the crew felt that had tried as hard as anyone
could, to deliver a user-centric world: as did the XRI folks, in support.
But, there was just no demand from the public. It was also 5-10 years too
early, tech-wise. AS we all know, sometimes a tweak makes all the

This is why Im wary of three things we keep alluding to: HTML5 is some
special kind of winner (to compete with OAUTH), DANE/DNSsec suddently does
correctly what signed XRD did not (for SSL server certs counter-signing, at
least), users with browsers will be controlling very trusted agents in the
cloud - that then orchestrate multi-agent flows (for such as the photo
printing use case); and,  then, in a world of poorly assured endpoints with
self-asserted identifies, some magical reputation service will evolve
(Nasdaq), based on web caching and triple crawling - doing facebook-style
be-friending, be-liking, and be-dumping when you break a rule.

Beyond an authorization logic for attributes and statements, Im looking for
our trust claim. As it stands, I see folks mixing topics. Just believe, and
it will come out in the wash. No it wont. It just makes for crappy crypto,
that no one with an auditor will adopt.

My gut tells me that we want a query server (ideally sparql) that can simply
compute trust chains - the sequence of foaf cards that link webid X and Y.
That query service will itself be a webid-powered endpoint. It holds the
cache of my reliances on foaf cards, and it computes my particular closure
(and yours, and Henries...).

Joe's and Kingsley's sparql services are close here. We just need the
queries, and the multi-tenancy.

Then we stop. We leave the rest of markets, for now. We let OTHERS add
criteria and compute metrics, that judge whether one closure is better than
another. One group that can do this is the federated social web folks of
course, "adding" value to webid. But, so can n other groups, that focus on
other criteria that the social web cares little about.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Melvin Carvalho
Sent: Monday, May 02, 2011 11:18 AM
To: Peter Williams
Cc: Kingsley Idehen; public-xg-webid@w3.org
Subject: Re: webid trust model, one or multiple?

On 2 May 2011 19:10, Peter Williams <home_pw@msn.com> wrote:
> But society thinks it has special rights to define the privacy space. Us
has decided that google et al should enforce it (whatever it is) on your
behalf. Those who consume websso profiles are governed by google, concerning
use and reuse.
> The single most important thing trust thing we have to address is ensure
multiple idps support your access to sites - and they do not know of each
others existence.

Yeah it's kind of a shame that hosting your own OpenID become less of a
focus.  In fact I think live journal who invented OpenID as a system to
federate ID probably dont have access to most OpenID relying parties these

The idea of giving choice in trust, is hopefully similar to what blogs did
to traditional media.  Giving more choice to the end user in terms of who
they want to get their information from.

I think it's a sign of going mainstream when the president of the united
states recommended broadening your horizens by putting down a news paper and
reading some blogs from time to time.

It's hopeful that Identity, and WebID in particular, can help bring about
that kind of choice and put users more in control of how they use the Web.

> This (re) balances the power.
> This is where openid ultimately failed. Let's see how webid does.
> On May 2, 2011, at 5:31 AM, Kingsley Idehen <kidehen@openlinksw.com>
>> On 5/2/11 7:44 AM, Melvin Carvalho wrote:
>>> On 1 May 2011 20:37, peter williams<home_pw@msn.com>  wrote:
>>>> Is there one webid trust model, or are there to be multiple – 
>>>> because the IX about standardizing “a framework” for trust 
>>>> overlays? If it’s a framework, I see value in using logical 
>>>> description “enabling” trust metrics, generically. These can drive 
>>>> link chain discovery, as usual. It’s criteria based search.
>>>> Im trying to decide where to spend my time in the next three 
>>>> months. There is no point me being involved in something I don’t 
>>>> believe will ever work (standardize a single trust metric). I might 
>>>> as well get out the way, if this is the group’s mission.
>>>> If it helps motivate the decision, a realworld user story of 
>>>> handling macro-trust issues – at national scale - may be applicable.
>>>> There is just no way I can impose a trust metric on my very local, 
>>>> de-centralized customer base – as they network using the social 
>>>> web. They will quickly slap me down for even trying, let alone 
>>>> agree with any given proposal. They SEEK local variance in trust 
>>>> etc. It’s what distinguishes their value, in the subtle “business 
>>>> social networking” scene found in selling real-estate to migratory 
>>>> populations, or as folks change lifestyle with age, income brackets,
>>>> The that scene, one sells trust in “gated communities” to one 
>>>> person, and one sells “iron bars on the windows” to another. Some 
>>>> communities measure trust in the absence of broken cars in the 
>>>> street, or absence of side-walks in country streets; and the 
>>>> realtor will project that value system. Trust, safety, confidence, 
>>>> and assurance are all variant terms, that get bandied around.
>>>> Others communities have more divisive trust measures, often 
>>>> obliquely stated or enforced. Somehow the independent realtor as 
>>>> trusted agent has to mediate even these issues (which obviously
requires  ALOT of social finesse).
>>> I think this paper is an excellent model
>>> http://www.cdm.lcs.mit.edu/ftp/lmui/computational%20models%20of%20tr
>>> ust%20and%20reputation.pdf
>>> It basically says there's an element of trust that is subjective and 
>>> an element that is observed
>>> Trust is per individual and per group
>>> Observed trust can be direct through interaction or observed, or 
>>> indirect through reputation of a individual or group, either prior 
>>> or propagated
>>> It's a relatively complex model, but then trust is a hard thing to 
>>> model and can get very complex.
>>> One reason I'm excited about WebID is that it's possible (longer 
>>> term) to model complex concepts such as trust as data and ontologies 
>>> develop
>> When all is said an done, this is basically about the power of data
access by reference combined with logic based schemas. As I state
repeatedly, this is the "holy grail" for those who've grappled with these
matters long before the emergence of today's ubiquitous InterWeb.  It is
also why the real narrative has to be about how contemporary infrastructure
(InterWeb, URIs, and EAV) have emerged to solve some really old headaches.
>> OpenLink built and sold secure ODBC drivers to corporations (still does)
on the back of a trust graph based on data containers (files) hosting EAV
content using the old INI notation for graphs. It's how we were able sell
drivers that handled scenarios like departmental partitioning such that
payroll, pensions, 401K data etc. was protected via enterprise specific
rules i.e., we gave our customers the infrastructure to implement their own
rules etc..
>> Today, WebID enables us to deliver the same functionality via URIs, EAV
based Linked Data graphs (RDF and other formats), SPARQL, and user definable
trust models (ontologies).
>> Privacy (where vulnerability is calibrated by the vulnerable) is the
biggest problem on this planet today, due to InterWeb ubiquity. We now have
critical infrastructure in place for addressing this problem head-on.
>> --
>> Regards,
>> Kingsley Idehen
>> President&  CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
Received on Monday, 2 May 2011 21:35:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC