- From: peter williams <home_pw@msn.com>
- Date: Mon, 2 May 2011 14:34:49 -0700
- 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 side-show. 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 difference. 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 days. 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> wrote: > >> 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, etc. >>>> >>>> >>>> >>>> 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