Reputation Services

Document Charter Reputation Services WG (repute)
Title Reputation Services
Last updated 2011-11-07
State Approved
WG State Concluded
IESG Responsible AD Pete Resnick
Charter Edit AD (None)
Send notices to (None)


In the open Internet, making a meaningful choice about the handling
      of content requires an assessment of its safety or
"trustworthiness".       This can be based on a trust
metric for the owner (identity) of an       identifier
associated with the content, to distinguish (likely)       good
actors from bad actors.  The generic term for such information  
    is "reputation".  This working group will develop
mechanisms for       reputation reporting by independent
services.  One mechanism will be       for a basic
assessment of trustworthiness.  Another will provide a    
  range of attribute/value data that is used as input to such an  
    assessment.  Each service determines the attributes it
reports.         Various mechanisms have been developed for
associating a verified       identifier with email content, such
as with SPF (RFC4408) and DKIM       (RFC4871).  An
existing reputation query mechanism is       Vouch-by-Reference
(RFC5518). It provides a simple Boolean       response
concerning a domain name used for email.  The current working  
    group effort will expand upon this, to support additional  
    applications -- such as Web pages and hosts -- and a wider range
of       reporting information.        
Given the recent adoption of domain name verification for email,    
  by SPF and DKIM, the most obvious initial use case for reputation is
      for email.  Inbound email filters that perform
message authentication       can obtain a verified domain name
and then consult a reputation   service       provider to
make a determination (perhaps also based on other       factors)
of whether or not the content is desirable and take      
appropriate action with respect to delivery, routing or rejection.  
      Another possible use case is identity-based evaluation of
web       content using technologies such as the DKIM-derived
DOSETA       (work in progress).        
This working group will produce specifications (targeting the    
  standards track, though the working group will determine the  
    appropriate status) for:            *
the detailed requirements for reporting            *
an end-to-end system architecture in which reporting occurs    
       * the mechanisms and formats for reporting    
    Two mechanisms are under consideration:      
     * simple -- a reputation is expressed in a simple manner,  
                   via records in
the DNS                  (see
draft-kucherawy-reputation-query-dns)            *
extended -- a response can contain more complex information    
               useful to an assessor,
reported over HTTP using              
         an encoding such as XML or JSON    
draft-kucherawy-reputation-query-http)         The
syntactic and semantic aspects of mechanisms and formats will be    
  designed to be application-independent and portable (i.e., reputation
      provider-independent).  By distinguishing reporting
information       (format) from reporting mechanism (channel),
the specifications       will permit adaptation to support
reporting through additional       channels.  Limited
application-specific tailoring will be       provided for email,
to demonstrate the approach, which can be       applied for
supporting additional applications.  The design and      
specification will also permit adaptation to support reporting    
  through additional transport channels.         Items
that are specifically out of scope for this work:        
   * Specific actions to be taken in response to a reputation reply.
           It is up to assessors (i.e., the consumers
of reputation data)            to determine
this.  Non-normative illustrations, however, can      
         be included to demonstrate possible uses of
reputation data            in a particular context.
           * Selection of what data might be valid as
the subject of a            reputation query.  It
is up to reputation service providers and           
assessors to select which qualities of a body of data might    
       be useful input to reputation evaluation.    
       * Concerns about methods of verifying domain names that
are used            for email reputation.  A
verified domain name is a starting point           
for this work; the means by which it was obtained and the      
     "meaning" of the name or its verification are matters
for            discussion elsewhere.    
       * Algorithms to be applied to aggregated feedback in
order to            compute reputations.  These
are part of a back-end system,   usually        
   proprietary, and not appropriate for specification as part of  
         a query/reply framework and protocol.  
      The initial draft set: