This
work is licensed under a Creative Commons
Attribution 2.5 License.
Other texts
WebDSign: thrust the Web by trust
A French summary exists: résumé en français.
This document describes an approach which offers a way for the Web user to
obtain various informations about an online document:
- origin, even when reading a quote from a quote from a copy from a
reference(...) (this function answers the question who wrote
this?),
- integrity (do I read the exact information or a tampered
version?),
- timestamping (since when this document exists?),
- non-repudiation (can the author negate being the author?),
- opinions and certification (what do people trusted by me think of
the document? Of the author? Of opinions expressed about this document?...),
- ...
WeBDsign transforms data published on the grafitti-wall-Web into rock-solid
information. It derives authentication of documents into authentication of
information (thanks to ooper for this one!).
The proposed logic does no check itself any document, it only produce
certificates and seals (they are common task) and gather informations about
published seals (which certificate created it? to which document is it
attached? where are the emitted opinions/critics?...), sent by the tools
used by their authors to create them. A browser extension will inform the
user, for example, about how people he trusts judged whatever he is
reading.
The goal is to convey "real life" trust on the Web, thanks to seals
describing and protecting information. WebDSign does not create confidence
or trust by itself, it simply let anyone will be able to create a
seal. Each seal establishes one or more of its author's statement
about a given published information, therefore each seal expresses a
relation established between its author and the information sealed:
- origin ('authorness'), integrity... and will to not negate them,
meaning "I'm the author of this information"
- agreement, meaning "I agree with (or like) this information" or,
reciprocally, "I don't agree"
- certification ('truthness'), meaning "I state that this
information is true" or, reciprocally, "this is false" or
even "I don't know". This seal is probably only meaningful for a visitor
who thinks that I am an expert in the field
- timestamp, meaning "I saw this information at this date and
hour"
- ...
As of the beginning of 2008, WebDSign is (since 2002) a set of concepts and
a few snippets of code. I'm looking for co-founding associates and
contractors, please contact me.
Description
Don't miss our slides.
Some benefits
The proposed method:
- offers to anyone a way to trust an information published on
the Web,
- eases automatic discovery of similar tastes (may I obtain the list
of all informations new for me and appreciated by other Web user emitting
opinions similar to mine?), for instance favorite topics and opinions
shared by coherent groups of Web users (it may lead to some collaborative
filtering),
- eases automatic measure of people agreement (done by software crawling
the Web) and even qualified (with conditions, for example count only
certifications made by people trusted by me: my list of friends, their
directs friends and anyone using a certificate signed by an academic US
institution).
- offers a way to layer (may I automatically access preferably/only
to information validated by a set of people trusted by me?)
Interested? Please let me know!
Interested? I'm looking for co-founding associates and contractors, just drop me a note!
.
Any comment or suggestion will be welcome.
GPG: 0230D602
WebDSign is exposed and discussed at Cambrian House
Vocabulary
A 'atom', here, is a chunk of information published on the Web
(i.e. storable into a correct (valid) XML node).
Each is meant to be quoted, if possible in full form. That's because no one
wants distorted quotes, no one wants to be quoted off-context (you say "I
agree with John when he says that the sun shines" and people quote John
saying "The sky is green" then your sentence truncated to "I agree with
John". Ouch!). Therefore each and every WebDSign atom is coherent, it is an
'atom', created and sealed by its author. Each atom can be of any length
and can quote other atoms, or (for non-repudiation purposes, therefore in
order to forbid the criticized author to withdraw his words) even integrate
a copy of some of them. The easy (and 'default') way is to seal while
publishing is to seal the whole document (web page). All the necessary
signature functions are done by the authoring tool: the author selects an
atom (by highlighting it, as usually done) then clicks a 'seal' button (he
has to have his certificate on the machine and to type, once per session,
his passphrase), he then can express wether he wants to only sign or to
give an opinion about it, certify it...
A certificate
(short for 'digital certificate') is a digital piece of information
enabling someone to be identified and somewhat described.
A certification
authority signs certificates, injecting into them some
dematerialized trust.
A seal (short for 'digital seal', used here as a replacement for digital
signature) offers here an efficient way to express that a given
identified person (she uses a certificate in order to seal) expresses some
opinion about an information (for example "I'm the author" or "this is
true") in a way that, thanks to some cryptography, anyone can be quite sure
that this person (not anyone else) sealed this particular
information (which was not tampered with).
Approach
From an authors standpoint: in order to publish trustworthy information on
the Web you have to let the reader be pretty sure that you wrote it
and that the document he reads is exactly what you wrote. You may
also want to be able to prove that you was the first to publish
it. Moreover you may want to show who agrees or certifies the
information, and anyone expressing such a comment (from a mundane comment à
la weblog all the way up to database-powered scientists' peer-review) may
want to publish it for any interested party.
WebDSign can deliver all those insurances. To do so it specifies
conventions and tools enabling any atom of data (text, images ...) to be
published, for example by a Web or RDF server, along with meta information
which seal it in order to convey all those warranties.
Any browser will be able to interpret, check and (upon successful checking)
present any sealed information as such, for example by displaying it on a
graphic box using colors revealing the type (statement: origin,
agreement...) and author of the seal. The reader may then obtain some
related information (who guarantees the seal author identity...).
Any real human can obtain a well-signed certificate (right now: a PGP-GPG key), right now and for free. It
can be used, through WebDSign tools in order to create a seal and then to
publish it.
Any seal can be accepted by the information publisher and therefore
published on his site, along with the information. Any visitor will obtain
it.
Some information publishers may not want to publish, along their own
documents, seals about it created by others in order to criticize, for
instance because they may express 'I disagree' or 'This information is
false'. Therefore any seal can also be published on a seal-publishing
server, for all browsers to use it (as a layer) in order to present those
seals when appropriate, i.e. when reading the sealed information.
Any action (seal creation, exploration, publication configuration...)
needed to create or maintain a seal will be performed through a standard
document authoring tool or browser.
Any Web user can configure his browser in order to ignore some sealers
(certification authorities, particular certificates).
A user may configure that only his own seals are to be taken into account
when calculating the score of a sealed document. He may also let it take
into account people he respects and trusts (let's call them 'friends')
seals. And even their friend's ones. Some will want to use coefficients,
upon the 'distance' in this chain of trust, or for given individuals, or
with respect to the topic. Or ignore any seal produced by somebody only
criticizing him (or his friends). Some may want to give confidence to seals
of people working in a given university, political party, whatever (and
their friends... or not). Some may edit official lists of trustable
certificates, for you to adopt (or not). There will be a standard and sound
configuration, inherited from existing 'web of trust' models, and everyone
will be able to tweak it, even on-the-fly (you read something cool, you
search other documents by this author, coolness is at max, you configure
your trust to him at a fairly high level. Some of your friends, who decided
to give trust to whoever you trust, will automatically trust him/her, maybe
a in a somewhat lesser extent because they want some damping/decay during
such inheritance).
A user also can enable people he trusts to filter the Web for him: he will
be warned upon access to a not or badly appreciated one. His browsing
experience is somewhat 'layered' by other's.
To do so we will use XML-Signature (RFC 3275), which uses
OpenPGP and X.509.
The existing virtues (or pitfalls) of the underlying schemes will be
available:
- seal expiration,
- web of trust,
- CRL -
OCSP ...
Moreover, using existing and open (publicly available) approaches leads to a
development benefiting from existing code and certificates.
Misc technical considerations
An adequate Web browser will:
- only display verified and valid seals,
- not display anything which can be visually mistaken for a graphic
thingie revealing a seal,
- offer many configurable ways to reveal or hide any seal presence with
respect to various parameters,
- offer various ways to examine seals (Web of Trust exploration...),
- offer various functions for sealing, publishing the seals, declaring
layers, interacting with remote dedicated seals servers
Any atom can have multiple seals, even overlapping. Any seal producer
can seal the very same atom multiple times. He can use expirable seals
and also instantly revoke a seal (it will not be restorable afterwards).
Snapshots
Here are some descriptions and ugly-but-commented pseudo-snapshots,
presented for each 'role': 'author', 'evaluator' (emitting opinions),
'reader' (browsing the Web). Any WebDSign user can freely embrace any role
at any moment.
Author
The authoring tool let him save a document which is automatically sealed in
order to sign it (claiming "I'm the author") and to preserve its
integrity. Clicking on a menu item or button seals the currently selected
zone(s) of the document. The authoring tool, while uploading on the website
(for publication), communicates to the WebDSign central site various
informations about the seals and publications URLs. Each seal has an ID,
calculated at creation time (without involving the central database).
Evaluator
(He is a 'reader' then...) He wants to comment the document displayed or
selected. He selects the corresponding seal or, if there is no seal,
creates one (a dedicated type dubbed "I saw this"), then chooses a WebDSign
browser extension button or menu item launching the function "Create an
opinion", then sees a WebDSign window or frame containing:
- a view or abstract of the seal and atom contents, with an underlying
link to its contents
- a widget (examples: checkbox or radiobutton) enabling him to state
wether he agrees or disagrees with the atom's contents. The answer is
optionnal
- a widget enabling him to state wether the atom is true (factual,
objective...) or not. The answer is optionnal.
- a widget him to comment, to phrase its opinion. This can be a text
area and an "upload file" service
If he doesn't provide any material the seal is not created.
This describes the standard opinion 'template', other ones may be created
by every user by copying an existing template then adding fields to it. An
opinion template for texts, for example, may also ask whether the contents
are exhaustive (covering all pertinent material),
accurate (clear, articulated...) and brief (concise).
Reader
A 'reader' is a WebDSign user who is just browsing (and may instantly
become an author or evaluator).
Here are a 'reader' browser's potential way to display seals. An ideal
extension will offer many customizable ways to do it.
Any WebDSign-ready browser offers a menu offering at least:
- "enrich". Enriches the current frame displayed with informations
related to its seals.
- "analyze". Leads to a panel showing informations about seals stored
in the currently displayed document. For each seal it offers a mean to
order:
- verification (signature and integrity)
- score, established with respect to the opinions expressed by
whoever the user declared (in a configuration panel) as trustable (this can
encompass his friends, experts, institutions...). The user can use trust
coefficients and the calculation evaluates the web-of-trust (opinions
expressed by people trusted by persons trusted by the user, and so on up to
the Nth level)
- access to comments made about this seal
- "comment" (creates an opinion seal, the 'reader' then embraces the
'evaluator' role)
- "browse through trusties" (access to the 'layers' function)
Browsing
Here is a atom (part of 'page') published on the web, without any
seal:
A atom of this document is 'signed', as revealed after launching the
'enrich' function of WebDSign (which may be always activated), by a red
border which means 'this information has an author and was not tampered
with':
By clicking on the red border (or on some graphic handle conveniently
provided) the visitor will gain access to a document generated by his
browser (we do not provide any mock-up here), stating various pertinent
information (who signed, when, who signed the certificate used...).
The atom certified ('truthness', revealed by a blue border) by 2 known
parties and 8 unknown ones:
A click on the border will (as usual) let the browser display various
informations about those seals.
Atom sealed as above plus sealed in order to express 'I agree' (green
border) by 0 known, 3 unknown and 4 untrusted:
Note: those seals apply to the information, therefore a border included
into another is not sealed by it (i.e. those snapshots show seals sealing
information, not seals sealing seals).
Seals may apply to seals, in such a case the corresponding boxes will be
linked.
By clicking on a border the visitor will access to a set of linked
documents created by his browser in order to describe the seals.
Services
Any seal can express at least one of the following assertions:
Authorship (signature)
It means 'I am the author of this particular atom of information'
It is always coupled to a seal, meaning 'I am the author of this seal'
Done by providing a cryptographic mean to prove that [s]he is the author of
this particular atom (therefore also providing a way for anybody to
check that the document was not modified).
Application: fighting against astroturfing
Anyone can use his certificate to seal any atom written by him/her in
order to prove that somebody (as opposed to an empty digital ID) stands
behind his published statements (for example a comment posted on a blog).
Timestamping
A service may provide seals (with legal value) establishing the publication
date and the signing certificate. It can charge for it (there is a biz
model here).
Application: creating proofs of origin and first publication date
Anyone may thus establish the origin and publication date of a published
information.
Voting
This particular seal means 'I agree with this information'. It may useful
for voting purposes.
This is a can of worms but direct democracy may progress if any web user
can publish a petition and gain certified signatures, proving that it
attracts sympathy which anyone can automatically measure with respect to
the certification authorities he trusts. This leads to concerns, for
example about the representative character or even the adequacy of direct
democracy, well above the topic.
Expert seal (certification of truthness)
Experts may seal part of a atom in order to convey to the reader a
certain degree of trust-confidence, stating "this information is true, I
put my reputation on it". He can also state that he does not agree or that
is has no opinion (the mu state).
Any seal can only be produced by somebody using a certificate
browser will let the user declare the certification authorities he
chooses to trust or distrust. On the client side it will govern the
rendering (display), on the server (for example Apache) side it will govern
the acceptance ('automatic', 'spool for manual checking' or 'reject') of
submitted certificates, which will in turn be published along with the
pertinent atoms.
Each atom of published information sealed by a trustable (as configured)
entity will be displayed in order to let the user know that it is sealed,
and access to a document describing all seals: meaning (agreement,
timestamp, validation by an expert ...), author (and the corresponding
trust tree), date...
Application: approval/certification
It may be used by an expert, for a document published online authored by
somebody willing to manifest that at least an expert agrees.
Seal publication
Anyone using a browser and a certificate will be able to produce a seal. By
default the seal will stay on his machine which may publish it.
Anyone can declare to his/her browser the URL of a server publishing the
seals of trusted sealers or group of sealers. The browser will then present
these seals.
A seal can also be submitted to the publisher in order to be published
along with the atom. Any publisher will be able to choose whether his
server will host and publish any certificate. This tedious process can be
eased by letting the publisher elect some seal producers to be
automatically rejected or accepted (and some filters may be provided by
seals publishers).
Implementation
The seal-publishing server can be a Web server, using a specific protocol
able to grok an URL submitted, disambiguate it, then provide a list of
pointers to the corresponding seals.
Seal revocation may be resource-hungry if it implies that each and every
seal is somewhat OCSP'ised. A cache and a manual 'confirm' procedure
implemented in the browser may tackle this.
The 'layers' implementation is difficult because it needs some unique
address for a given atom, but some of them may be published under more
than one URL. We cannot use the atom's digital fingerprint as an ID
because when browsing the browser only has the document, not the atoms
(and any document has a huge number of potential atoms).
Pertinent information
Our objectives are:
- avoid annoying anyone who likes the way Wikipedia works now
- satisfy anyone who prefers reviewed articles
In order to do so each Wikipedia article may have more than one status,
optionally used and displayed:
- 'raw' (or maybe 'vanilla'?), meaning 'last standard content' (any
existing article has this 'raw' status)
- 'unpolluted', meaning 'free from any vandalism'
- 'validated', meaning that 'a Wikipedia commission of people knowing the
field validated it'
- 'expertised', meaning that 'a world-known expert of the field checked
it ok'
Discussion
Wikipedia is a success because it has many good articles
Experts on any field are such because the are recognized
If Wikipedia delivers a 'Wikipedia expertise score' which gains popularity
then many professional experts on various matters will be interested in
obtaining a good score, in order to let prospects and customers know that
their knowledge is recognized everywhere, even on Wikipedia. It will
motivate experts to write and validate articles thanks to a challenging
approach
A 'Wikipedia expertise score' will be delivered to every Wikipedia-account
owner who writes at least an article. It will be a cryptographic
certificate holding a value (the 'expertise score'). Any expert will be
able to publish his score (certificate) and anyone will be able to verify
it because it will be digitally sealed-and-signed by the Foundation managing Wikipedia
A contribution (information created by a given Wikipedia account) will be
considered as be good if it read by many. Moreover every expert can
validate or challenge it. The first validator of a given article gains a
whole lot of points, the next one gains less, and so on. The best way to be
the first validator is to write the article, and any expert has available
material for this, therefore he can do it and will earn
(recognized expertise score) from doing so
Any expert finding a factual error (validated as such by many others) will
take a good fraction of the points earned. Any expert claiming he found an
error then failing to obtain validation of this claim by other
experts... will lose points.
Therefore the articles will be created, maintained and reviewed by a pool
of score-seeking experts:
- their authors, acting to
- enhance their scores by creating articles
- sustain their scores by maintaining them at a bulletproof stage
(any point given to the author of a correction is taken from the
author's score)
- other experts, trying to find errors in order to enhance their
'Wikipedia expertise score'
Pitfalls :
- an expert gang may falsely 'vote wrong' in order to rack points. But
using the existing (today!) set of articles an automagic analysis of the
volume of information produced and its relative stability ('unpolluted'
status, age and amount of readers) the motivation and efficiency of all
their authors can be calculted ('scored'). Therefore a software can already
(right now) establish a 'confidence score' for each already registered
author. The first stage of this operation is therefore to deliver a score
to each of them. They are of good will and will devise a way to deliver
other certificates.
- some people may try to trick the system in order to sell expertise
points by various means. All points are created by publishing original and
valuable information, therefore I don't think that anyone will be able to
benefit from those points in order to gain anything than spare time.
Implementation
Any Wikimedia visitor will be able to state in his profile that, upon
reading, [s]he wants to obtain the last version of any article which
reached a given status. If there is no such version the immediate
'lower' status will be published (this is recursive)
This will not in any way annoy the reader who does not care about
article status because the default (in the personal profile
(preferences) of each registered user or for anonymous ones) will state
'raw'. Moreover on each article displayed a new tab will offer access to
the various other accessible versions
Those various articles status will be expressed by cryptographic seals. It
is not mandatory as most functions proposed here can be implemented using
standard version-tracking tricks (taging, branching...) but some people may
want to have their screwed articles published with a forged status and try
to tamper the servers or network connection. Let's integrate security
concerns as soon as possible (more about this).
The WebDSign protocol
may be the technical foundation of such seals.
Usage
All processes (requesting-delivering-managing certificates, sealing,
obtaining information about a seal...) will be done by a Web navigator, as
'transparently' as possible.
In order to produce a seal one needs a digital certificate (X.509 or
OpenPGP (PGP-GPG)), delivered (X.509) or signed (PGP) by a certification
authority (CA), which will be Wikipedia organization. Anyone can check
that a given certificate (and all information it stores) was issued by a
given CA.
Any account owner (i.e. any non-anonymous Wikipedia contributor) will carry
only one Wikipedia certificate, which will store many attributes
stating various useful parameters.
'raw' status
Default status of any article
'unpolluted' status
Any administrator (or 'RC patroller'?) will obtain a certificate in order
to let him/her give the status 'unpolluted' to any article which does not
contain anything blatantly off-topic.
'validated' status
Using the existing (today!) set of articles an automagic analysis of the
volume of information produced and its relative stability ('unpolluted'
status, age and amount of readers) the motivation and efficiency of all
their authors can be calculted ('scored'). Therefore a software can
establish a 'confidence score' for every already registered author.
Administrators will deliver certificates to authors obtaining the best
scores. Every certificate will be qualified by an attribute (named
'wpexpert' ) listing the name of the categories of expertise of their
carrier (themes, for example 'mathematics' or 'geography'), which are the
very main categories of the articles they contributed to. Those authors, in
turn, will recognize some other authors (for example newcomers) as peers.
As M. Subramanian puts it: any 'stable' status is to be dropped when an
unexpected ongoing event happens to the subject of an article.
'expertised' status
In each category this first college of 'wpexperts' will be enabled to form
a college in order to elect world-known 'experts' of the field. The CA will
produce certificates for them, with an 'expert' attribute storing the
pertinent categories names. At first they may be not very interested in
participating but as more and more will somewhat do emulation will raise
their involvement (Wikipedia will benefit from it).
Future version
As each article contains atoms (chunks) of information further developments
may enable the underlying software (Mediawiki) to dynamically build every
article by using the last version of every atom corresponding to the
visitor's preferred status. This implies some way for the contributor to
declare interdependancies between atoms.
Business model
Certificate-selling
For authors wanting to be immediately recognized by the central
system. They can buy one elsewhere or even create it but buying it at the
central site will enable them to be recognized under their real identity
(this is useful for experts, journalists...).
Technical note: we will offer all pertinent PKI-related services:
centralized (default) and decentralized (sort of escrow enabling for
example a company to recover/revoke a certificate misused by an
ex-employee) modes, 'n of m' (certificate issued to a group of 'm' members,
only usable if 'n' members agree to do so)...
Cross-certification
Certificates issued by third parties (certification authorities, for
example Verisign or an in-house PKI) will be honored by the central system
as providing an identity proof
Any standard (X.509) certificate will be recognized and used but WebDSign
will not guarantee identities not certified by a certificate issued by its
central system or by a cross-certified authority. Even anonymous users will
know the central site and therefore may be more confident to buy there
(through some anonymizing apparel), without disclosing their identity and
at a bargain.
Timestamping
For authors wanting to be able to prove that they were the first to state
something we will sell a service 'you send the atom, we add timestamp to it
then sign the whole'. In fact we will use existing timestamping services,
recognized by various jurisdictions
Alerting
The 'alert, something you criticized/liked/disliked/whatever changed!'
service, not tied to any action/dissimulation of the information
publisher. Think 'sort of RSS able to automatically alert after a
modification even if the author does it discreetly, without announcing
anything', if necessary with filters (distinct alerts for different
modifications types/authors/...)
Layering
The 'layer' enabling users to let browsing benefit from opinions emitted by people they trust. Some basic functions, for example 'Browser, show me the list of all documents liked by my pals' will be free. The function is similar to StumbleUpon's but forbids pollution (for example astroturfing). Enhanced stuff will lay on collaborative filtering and be an invoiced option.
And also...
There are other underlying money-making projects, for example specific
voting or decision-making systems, experts guilds...
TODO
- modify this document in order to describe subprojects from the more
useful, simplest and easy to grasp to... well, to the rest
- Trust and
Reputation in Web Based Social Networks (and scholar.google.com),
Online
Reputation Is Hard To Do (/.)
- Wikipedia: analyze Article
validation,
Article
validation proposals and Sam
Spade policy proposals
- Karma
Whores on /.. Similar to the dynamics of groups composed of individuals
each systematically (agreeing with) or (validating) any information
published by another one
- Wikipedia: there is no need to convince any existing Wikipedian because
the content is free, therefore one may think that a test can be established
on a server by slurping data on WP (not accessing to the underlying
database will be an annoyance but may be tolerable for a benchmark)
- Firefox: development of an open source Firefox plugin which will at
least recognize, check and show the seals, then offer all related
information. This plugin may then offer a way to create seals. Make it easy
to client-side-customizing, for example with Greasemonkey
Ack
Thanks to Benjamin Sonntag, Tristan Nitot, Jean Peyratout, Satya
Subramanian, David Latapie, Karl
Dubost, Eric van der Vlist, Sbi, WJ and
some of the Cambrian
House folks (the site masters, Kevin_Cox, tlyden, ooper, PeeJayEl) for their
useful inputs on this matter.
Thx to the guys from the PGP, OpenPGP, GPG, W3C and Apache projects who
already described or even realized most of the necessary tools and
protocols.
Other texts