W3C home > Mailing lists > Public > public-wsc-wg@w3.org > February 2007

Re: Clarifying "reputation service" in section 7.7 of the Note

From: <michael.mccormick@wellsfargo.com>
Date: Mon, 12 Feb 2007 12:01:13 -0600
Message-ID: <8A794A6D6932D146B2949441ECFC9D6802B4D2AA@msgswbmnmsp17.wellsfargo.com>
To: <public-wsc-wg@w3.org>
Responding at Mary Ellen's request.

I'm not the most qualified participant to supply detail for the Note on
reputation services.  If we have any participants from the phishing
toolbar vendors (?) then I gladly defer to them.  Here's what I can

Web reputation services in the past typically were provided via
so-called phishing toolbars from companies ranging from Cloudmark &
Whole Security to Norton & Symantec to Google & Yahoo.  Building
reputation services directly into the base browser is a fairly new
phenomenon; MSIE 7.0 and Firefox 2.0 have incorporated native reputation
services for the first time.

Certain features are generally found in web reputation services.  From
most to least common:

1. Black listing.  The services maintains a list of known illegitimate
sites, mostly forged sites creating for phishing.  The black list is
maintained by the web reputation service provider (WRSP) sometimes as
part of a network in partnership with other providers.  In addition end
users are typically allowed to submit URLs for potential inclusion on
the black list.  When a user browses a black-listed site, a warning
indicator appears.  Access may also be blocked or made contingent on an
"Are You Sure?" dialog.

2. White listing.  The service maintains a list of known legitimate
sites, mostly sites of well known financial institutions and other
common phishing targets.  Companies who pass a vetting process (defined
by the WRSP) can request their site be added to the white list.  Some
WRSPs may charge a fee for vetting & white-listing companies who make
such requests.  When a user browses a white-listed site, a safety
indicator or "seal of approval" may appear.  The safety indicator may be
contingent on SSL with a certificate name matching the white list (see
item 4 below).

3. Intel & incident tracking.  A reasonably sophisticated WRSP has the
capability to perform intelligence gathering and incident tracking.
Some WRSPs may partner with another company for this (such as iDefense
or Websense).  Some WRSPs operate honeypot mailboxes to attract phishing
attacks and thereby gather intelligence and potential black list sites.
The WRSP updates its white & black lists in response to incoming
intelligence as rapidly as possible.  For example, a phishing incident
involving a spoof site at a particular IP address will cause that IP to
go on the black list.  Or a database breach at a major online retailer
might trigger its removal from the white list.  The end user may be
offered dynamic links to web site intelligence when trying to access
such sites (see item 5 below also).

4. SSL certificate analysis.  The WRSP may tie in reputation to the
strength of the SSL session a web site establishes (if any).  SSL
strength runs from none to low (e.g., self-signed cert) to moderate
(trusted CA, good cipher) to high (EV certificate, OCSP check passed,
etc.).  Reputation correlates proportionally to SSL strength because the
latter measures likelihood that the site is who it appears to be, and
any white or black list checks must rely on that site authentication.
When a user browses a site the WRSP may offer a visual indicator of SSL
strength, or the WRSP may modify its normal reputation indicators (see
items 1, 2 above) based on SSL strength.

5. Site metadata.  The WRSP may provide metadata about a web site to
help the end user make his/her own decisions about site authenticity and
risk.  Real world examples include WRSPs that display "whois"
information about the site and geo-location information about the site
(e.g., "site hosted in Ukraine").


I invite comments.  Underlined terms are those I feel should be linked
to a glossary definition or some other section of the Note for further
explanation.  I have not placed any of the above in the wiki.  Cheers

From: Close, Tyler J. <tyler.close@hp.com
hpqcorp.net%253E> > 
Date: Mon, 5 Feb 2007 12:07:25 -0600


The "reputation service" item seems too vague to me. The other entries
in section 7 are very specific. Could someone expand "reputation
service" into a list of specific security information available in
current web user agents? It could be that this item is actually already
covered by other parts of section 7. For example, installed CA
certificates are already listed in section 7.5. If so, we should remove
the "reputation service" item from section 7.7.

Received on Monday, 12 February 2007 18:02:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:14 UTC