A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 4, 2011. Reputation Services (repute) ----------------------------------------- Status: Proposed Working Group Last Updated: 2011-09-13 Chair(s): TBD Applications Area Director(s): Pete Resnick (presnick@qualcomm.com) Peter Saint-Andre (stpeter@stpeter.im) Applications Area Advisor: Pete Resnick (presnick@qualcomm.co) Mailing Lists: General Discussion: repute@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/repute Archive: http://www.ietf.org/mail-archive/web/repute/ 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 is 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 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 supportting 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
