[domainrep] WG Action: Reputation Services (REPUTE)

[IESG Secretary <[e-mail]>]

A new IETF working group has been formed in the Applications Area.  For 
additional information, please contact the Area Directors or the WG 
Chairs.

Reputation Services (REPUTE)
---------------------------------------------------
Current Status: Active Working Group

Chairs:
    Dave Crocker <[e-mail]>
    Chris Lewis <[e-mail]>

Applications Area Directors:
    Pete Resnick <[e-mail]>
    Peter Saint-Andre <[e-mail]>

Applications Area Advisor:
    Pete Resnick <[e-mail]>

Mailing Lists:
General Discussion: [e-mail]
    To Subscribe: https://www.ietf.org/mailman/listinfo/domainrep/
    Archive: http://www.ietf.org/mail-archive/web/domainrep/

Description of Working Group:

  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
               (see 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:
      draft-kucherawy-reputation-model
      draft-kucherawy-reputation-media-type
      draft-kucherawy-reputation-query-http
      draft-kucherawy-reputation-query-dns
      draft-kucherawy-reputation-query-udp
      draft-kucherawy-reputation-vocab-identity

Goals and Milestones:

  Mar 2012:    Informational document, defining the problem space
          and solution architecture, to the IESG for publication.

  Mar 2012:    Specification for the multi-attribute reporting
          data structure, to the IESG for publication.

  May 2012:    Informational document, defining the vocabulary
          for providing reputation in the email sphere, to the
          IESG for publication.

  Jul 2012:      Specification defining the simple
          query mechanism, to the IESG for publication.

  Jul 2012:      Specification for the extended
          query mechanism, to the IESG for publication.

  Oct 2012:      Informational document, discussing issues
          of data transparency, redress, meta-reputation
          and other important operational considerations, to the
          IESG for publication.