UserPreferences

ReputationServiceSpecs

Reputation Service Specifications

  1. Introduction
  2. Reputation Service V1.x Specifications
    1. Working Drafts
    2. Referenced Specifications
    3. Service Type XRI
  3. Use Case – Contact Reputation
    1. Actors
    2. Preconditions
    3. Basic Use Case
      1. Case #1 - Negative Filter Result
      2. Postcontitions
      3. Branch #2 – Positive Filter Result, but Complaint
      4. Postconditions
  4. Requirements
  5. Proposed Design
    1. SAML Assertion Exchange for Contact Reputation Scores
    2. Complaints
    3. Contact Reputation Score
  6. Use Case – Third-Party Reputation
    1. Actors
    2. Pre-conditions
    3. Basic Use Case/Preliminary Design
    4. Postconditions

1. Introduction

This is the home page for community development of the specifications for a standard XRI-based reputation service. This first-generation service solves two problems:

  1. It uses peer feedback to identify and control spam (even human-generated spam) in V1 Contact Service (see ContactServiceSpecs). This is called Contact Reputation.

  2. It provides a verified link to a third-party reputation service provider (RSP) for independent reputational feedback. This is called Third-Party Reputation.

2. Reputation Service V1.x Specifications

2.1. Working Drafts

Working Drafts will be posted below. Please post any feedback on these drafts to this page.

Note: Subscribe to this wiki page to be notified when new Working Drafts are posted.

2.2. Referenced Specifications

The Reputation Service V1.x specs are dependent on:

2.3. Service Type XRI

Each XDI.ORG i-service specification defines an absolute XRI that is used as value of a Service/Type element in the XRID (XRI descriptor) for any XRI authority (person or organization) offering this service. See the XRI Descriptor section of the [WWW]XRI 2.0 Resolution Specification for more details.

For Reputation service V1.0 the proposed service type and version is: 

xri://$res*local.access/(+reputation)*($v/1.0)

3. Use Case – Contact Reputation

Following is the basic use case for Contact Reputation.

3.1. Actors

3.2. Preconditions

  1. Sender and Receiver have both registered at least one i-name with an i-broker. This i-name must resolvable in the XDI.ORG Community (meaning a global i-name, e.g., "=example.name", or a community i-name, e.g., "@example.org*example.name").

  2. I-Broker is required to offer Reputation Service as a precondition of registering with the XDI.ORG I-Broker network.

  3. Sender is provisioned at Sender's I-Broker to use ISSO service and is required to use Reputation Service as a precondition of receiving ISSO service.

[Aman Teja]: Why is this a precondition for using SSO? If the receiver has defined a policy to not receive contact requests from i-name holders who dont publish their reputation, then the ability of such people (who do not enable publishing of their reputation) to spam others does not exist

  1. Receiver is provisioned at Receiver's I-Broker to use ISSO service.

  2. Receiver has configured and activated a Contact Page.

3.3. Basic Use Case

  1. Sender visits Receiver's contact page and submits a Contact Request using Sender's i-name. (Note that reputation-based filtering only works with i-names/i-brokers, so it is a good reason to encourage contacts to get an i-name.)

  2. Receiver's I-Broker verifies Sender’s i-name and contact reputation and takes appropriate action according to Receiver’s policy.

3.3.1. Case #1 - Negative Filter Result

  1. Sender’s Contact Reputation does not meet Receiver’s filter policy, so Sender's I-Broker denies it (and no contact request is sent to Receiver.

3.3.2. Postcontitions

  1. (Optional) Receiver's I-Broker reports # of filtered contact requests to Receiver and Receiver is able to view if desired.

3.3.3. Branch #2 – Positive Filter Result, but Complaint

  1. Sender’s Contact Reputation meets Receiver’s requirements, so Sender's I-Broker sends Receiver Contact Request Message including Contact Reputation Score and Complaint Link.

[Aman teja]: Will the complaint have a fixed structure (xsd?) that the receiver ibroker can use to create a form and collect abuse report from a receiver, and be able to communicate that to ANY reputation service

  1. Receiver reviews Contact Request Message. If it is legitimate, use case ends. If Receiver feels it is an abuse of contact service, Receiver clicks the Complaint Link in the contact request.

  2. Receiver files a Complaint with Sender's I-Broker.

  3. Receiver is authenticated to Sender's I-Broker using ISSO.

  4. Sender is notified of Complaint.

3.3.4. Postconditions

  1. An authenticated Complaint is added to Sender’s Contact Reputation Score.

4. Requirements

To be extracted.

5. Proposed Design

Note: this design is modeled on the AOL Instant Messenger Warning Level peer feedback mechanism, which provides mutual authentication via the two participating AIM clients.

5.1. SAML Assertion Exchange for Contact Reputation Scores

  1. Receiver's I-Broker does a SAML attribute request for Sender's Contact Reputation from Sender's I-Broker that parallels the SAML Authentication Request done for ISSO. This could be either:

    1. A SAML Post/Post exchange done immediately after ISSO authentication of Sender, OR

    2. Accomplished inline in the same SAML assertion exchange done for ISSO.

  2. In either case, to prevent reputation attacks, Sender MUST approve the release of his Contact Reputation Score to Receiver's I-Broker.

    1. If Sender does NOT approve, Sender's I-Broker sends an error to Receiver's I-Broker and Receiver's I-Broker terminates the Contact Request process. (In other words, no contact request is sent by Receiver's I-Broker and no change is made to Sender's Contact Request Count by Sender's I-Broker.)

    2. If Sender approves release of his/her Contact Reputation Score, Sender's I-Broker MUST increment Sender's Contact Request Count and return Sender's Contact Reputation Score to Receiver's I-Broker.

  3. Following receipt of Sender's Contact Reputation Score, Receiver's I-Broker MUST send an SAML attribute request to a Community Reputation Service requesting the Contact Reputation Score for Sender's I-Broker.

  4. Community Reputation Service MUST send Sender's I-Broker a request to approve release of Sender's I-Broker Contact Reputation Score (the same way Sender needed to approve release of his/her Contact Reputation Score to Receiver's I-Broker). If approved, the Community Reputation Service MUST return the Sender's I-Broker's Contact Reputation Score to Receiver's I-Broker and MUST increment Sender's I-Broker's Contact Request Count.

5.2. Complaints

Note: the following links must contain XRIs that reference the original Contact Request.

  1. The Complaint Link MUST call a Complaint Form hosted by the Reputation Service for the Receiver's I-Broker (the i-broker the Receiver trusts.)

  2. Submission of the Complaint Form by the Receiver MUST be authenticated via ISSO.

  3. Once the Complaint Form is submitted, Receiver's I-Broker MUST post the Complaint to: a) Sender's Reputation Service at Sender's I-Broker, and b) Sender's Community Reputation Service.

  4. The Sender's I-Broker MUST send a Complaint Notification Message to the Sender.

5.3. Contact Reputation Score

Both Senders and I-Brokers have Contact Reputation Scores, and both calculated identically, the end result of which can be thought of as as a "batting average".

6. Use Case – Third-Party Reputation

Following is the basic use case for Third-Party Reputation.

The following is a preliminary outline only.

6.1. Actors

6.2. Pre-conditions

6.3. Basic Use Case/Preliminary Design

  1. User selects RSP and requests an Authenticated Reputation Link (an XRI that identifies User's reputation in the context of the RSP).

  2. RSP performs ISSO to authenticate User with User's I-Broker.

  3. RSP performs SAML Post/Post back to User's I-Broker of signed Authenticated Reputation Link.

  4. User's I-Broker confirms with User that User wants this new attribute.

  5. If User confirms, User's I-Broker stores Authenticated Reputation Link.

6.4. Postconditions

[Aman Teja]: What is community reputation service? Is it a service that maintains the reputation of the ibrokers? Who will run that? [Aman Teja]: How ill appeals function?