Open Reputation Management System (OR

Open Reputation Data (ORD) Draft Version 0.1

This document defines a generic and open format for exchanging reputation information among multiple parties who want to evaluate subjects such as online users, websites, and products.

Introduction
Overview
Terminology
Notation
Definitions
ORMS Reference Models
Portable Reputation Data Format
Reputation Input Data
Reputation Output Data Format

1. Introduction

1.1. Overview

A portable reputation data and meta-data format for exchanging reputation information between reputation data providers and consumers, a reference model is described. A portable reputation data format ensures openness in ownership, privacy and confidentiality protection and management of reputation data.

Reputation is a metric (a score, a rank, a state, a multi-dimensional profile, etc.) associated to an entity (a person, a business, a digital identity, a website, a system, a device, a category of devices, a computing resource, etc.) or to a tuple [entity, attribute(s)] (e.g. [person,skill]) in a particular domain and at a particular moment in time. Reputation in these examples refers to the opinions about an entity, from others. Reputation is one of the factors upon which trust can be based through the use of verifiable claims. Reputation changes with time and is used within a context. Trust and reputation are related to a context. An interoperable trust-scoring mechanism is required to relate the trust scores from multiple providers.

There are various methods for generating entity's reputation data or trustworthiness. Some methods are based on entity's feedback through appropriate feedback channels. Other methods include having viewers participate in the reputation-building process through the entity's profile at specific sites and communities. Each method has its limitations in terms of its susceptibility to bad actors, manipulation of data for specific purposes, and spammers.

Social and Corporate networking interactions in the Internet age have given rise to an exponential growth in real-time and asynchronous communications. The openness of the good-faith protocols and networks are now increasingly exposed to the threats and exploits of the community. Moreover, corporate networks and social networks are required to deal with a range of users with roles and privileges varying dynamically in time and (network) domain requiring corporations to adjust to the wired and wireless network, traditional and virtually-extended perimeters, extranets, federations and partner-portals involving considerable degree of transitive trust. A framework is required to

identify and qualify accidental, well-behaved and malicious privilege/usage patterns and
quantify (or trust-score) the above patterns to facilitate (social and corporate network) services adoption of trust levels and authorized accesses to resources.

The use of reputation systems has been proposed for various applications such as:

Validating the trustworthiness of sellers and buyers in online auctions (ecommerce websites have proved this can have a large influence on sellers)
Detecting free riders in peer to peer networks
Ensuring the authenticity of signature keys in a web of trust.
Smarter searching of web sites, blogs, events, products, companies and other individuals.

1.2. Terminology

1.2.1. Notation

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.2.2. Definitions

Reputation

Reputation is a subjective evaluation of the assertion about a subject being true based on factual and/or subjective data about it, and is used as one of the factors for establishing trust on that subject for a specific purpose. Reputation can be aggregated by rolling up opinions from smaller sets like individuals.

Reputation Systems

Using the Internet’s bi-directional communication capabilities in order to artificially engineer large-scale word-of-mouth networks where actors share opinions and experiences on a wide range of topics, including companies, products, services, and even world events. (Dellarocas (2005)) A reputation system may include mechanisms for: collecting data about entities (generating data inputs or integrating external data); computing reputations; making sure the system is fair (e.g. provide bootstrapping mechanisms for new entities); performing actions based on reputations (e.g. trust computations, automatic decisions); revoking reputations, allowing entities legitimate control over their reputation and allowing entities to challenge their reputations (governance); making sure the system is not abused (security), making sure privacy of entities is respected (i.e. that the association entity - reputation is only disclosed to authorized parties)

Reputation Score

A Reputation Score of a Player (Reputee) on the Type (Criteria) by other players (Reputor) is the subjective probability assigned by the Reputor that the Reputee fulfills the Criteria. (Sakimura (2008)) or subjective evaluation of fulfillment by the Reputer.

Reputer or Reputation Authority

The reputation-scoring service or the individual who evaluates entities.

Reputee

The actor whose reputation score is being considered or calculated.

Reputation (input) data

The data upon which the reputation is computed.

Reputation context

The encompassing domain where a reputation is defined (to be refined. how to distinguish from Context? A domain may take multiple contexts.) .

Reputation Compute-Engine (or RCE)

A reputation for an entity is computed using a Reputation Correlator, based on different sources of input data, about the entity. The reputation correlator accepts one or more input data about the entity, and evaluates a reputation score based on its algorithms and contextual information available at the time of computation.

Relying Party (RP)

Reputation Data Consumer.

Service Provider (or SP)

Reputation Service Provider.

2. ORMS Reference Models

The following figure represents a generalized reputation architecture model.

Figure 1 Generalized Reputation Model

Input sources: Reputation Input data collectors.
Portable Reputation Data: Portable reputation data generated by all input sources into a reputation computation engine (RCE or reputation calculator).
Reputation Context: This allows filtering and qualifying the right choice of algorithms to use and pre-process.
Reputation Score: the outcome of the reputation evaluation of an entity (to be portable).
Consumer: consumer of reputation score to use as yardstick for computing the degree of trust for the entity it serves.

Thus, the primary objective and challenge is to make the reputation input data and reputation formats interoperable (portable) across vendor-boundaries and domains of Reputation.

Figure 2 Reputation Reference Model [to be edited as we go along - ed]

3. Schema Organization and Namespaces

The ORMS document structure is defined in a schema associated with the following XML namespace:

The schema for [XML 1.0] (the "xml:" namespace), which is associated with the following XML namespace, is imported into the XRD schema:

The following [XML Schema] fragment defines the XML namespaces and other header information for the XRD schema:

<schema targetNamespace="
xmlns="
xmlns:orms="
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="1.0">
<import namespace="
schemaLocation="
<annotation>
<documentation>
Document identifier: orms-schema-1.0
Location:
</documentation>
</annotation>
...
</schema>

The location of the normative XML Schema file for an ORMS document as defined by this specification is: The following URI will always reference the latest version of this file:

4. Common Data Types

4.1. String Values

All ORMS string values have or extend the type xs:string, which is built in to the W3C [XML Schema Datatypes] specification. Unless otherwise noted in this specification or particular profiles, all strings in ORMS documents MUST consist of at least one non-whitespace character (whitespace is defined in section 2.3 of [XML 1.0]).

The following schema fragment defines the orms:string complex type, which extends xs:string to allow for arbitrary attributes (see Section 3.2, “Schema Extension”):

4.2. URI Values

All ORMS URI reference values have or extend the type xs:anyURI, which is built in to the W3C [XML Schema Datatypes] specification. Unless otherwise noted in this specification or particular profiles, all URIs in ORMS documents MUST consist of at least one non-whitespace character (whitespace is defined in section 2.3 of [XML 1.0]).

The following schema fragment defines the xrd:anyURI complex type, which extends xs:anyURI to allow for arbitrary attributes (see Section 3.2, “Schema Extension”):

4.3. Time Values

All ORMS time values have the type xs:dateTime, which is built in to the W3C [XML Schema Datatypes] specification. Time values MUST be represented with the UTC designator 'Z'. XRD providers MUST NOT generate time instants that specify leap seconds.

5. ORD Document Structure

ORMS provides a simple and extensible XML format for representing reputation. An ORMS document represents a subjective evaluation of the assertion about a subject being true based on factual and/or subjective data about it.
An ORMS document MUST (a) be a well-formed XML document as defined by [XML 1.0] with a root element of <Reputation>, (b) validate against the normative ORMS schema identified in Section 3, “Schema Organization and Namespaces”, and (c) adhere to the additional syntactic constraints defined by Section 4, “Common Data Types” and this section.

5.1 Element <ReputationBundle>

The <ReputationBundle> element can contain two or more <Reputation> elements to optionally make a group of reputation instances.
The following schema fragment defines the <ReputationBundle> element and its ReputationBundleType complex type:
<element name="ReputationBundle" type="orms:ReputationBundleType"/>
<complexType name="ReputationBundleType">
<sequence>
<element ref="orms:Reputation" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute ref="xml:id" use="optional"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>

5.2 Element <Reputation>

The <Reputation> element encapsulates the entire reputation document. It contains the following attributes and elements:
<Context> [One]

Context namespace. Identifier of the reputation context described by this document. See Section ?.?, “Element <Context>”.

<Subject> [One]

Identifier of the entity(reputee) described by this document. The entity could be a person, a business, a digital identity, a website, a system, a device, a category of devices, a computing resource, etc. See Section ?.?, “Element <Subject>”.

<Score type=" [One or More]

The reputation score.

<Date type=" [Zero or More]

The date data described by this document. See Section ?.?, “Element <Date>”.

<ds:Signature> [Zero or More]

This XML Signature, included from the [XML Signature] schema, protects the integrity of the document, as described in Section ?.
Although [XML Signature] allows a single document to contain multiple signatures, the signing profile described in Section ?, requires only a single <Signature> element. Use of multiple <Signature> elements in an Reputation document is therefore undefined. In order to aid certain types of Reputation consumers, it is RECOMMENDED that Reputation providers place the <Signature> element of a signed Reputation as near the beginning of the document as possible.

The <Reputation> element contains the following attributes and elements:
id [Optional]

This URI value defines an unique identifier of this document. (If the value in the <Subject> element is not the unique identifier of this document, this value MUST be assigned.)

rel [Optional]

This URI value defines the semantics of the relation among the multiple <Reputation> elements when they are bundled with the <ReputationBundle> element. Only the parent <Reputation> MUST contain the "parent" value in this attribute. All the other MUST contain the "child" to present that this <Reputation> subordinates the parent element.

The following schema fragment defines the <Reputation> element and its ReputationType complex type:
<element name="Reputation" type="orms:ReputationType"/>
<complexType name="ReputationType">
<sequence>
<element ref="orms:Subject" minOccurs="1"/>
<element ref="orms:Context" minOccurs="1"/>
<element ref="orms:Score" minOccurs="1" maxOccurs="unbounded"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="orms:Date"/>
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
<attribute name="id" type="anyURI" use="optional"/>
<attribute name="rel" type="string" use="optional"/>
<attribute ref="xml:id" use="optional"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>

5.3 Element <Context>

The <Context> element contains a URI value which identifies the context of the reputation described by this document. This value MUST be an absolute URI. The <Context> element is used as the namespace of the reputation context (or domain) defined by a data provider or a profile agreed among the data providers and the relying parties. The resource pointed by the URL MAY contain information or data to specify semantics and schema of other elements in this document.
The following schema fragment defines the <Context> element:
<element name="Context" type="orms:anyURI"/>

5.4 Element <Subject>

The <Subject> element contains a URI value which identifies the entity evalutated by this document. This value MUST be an absolute URI. Comparison of this value MUST be performed using the scheme- specific normalization rules for the URI, as specified in Section 6.2.3 of [RFC 3986].
-session unique identifier (id for the same reputation file changed based on timing) -> Should we specify the syntax?
-transient(SAML) or ppid(WS-Trust) (globally unique but pseudonym) -> Security Consideration?
The following schema fragment defines the <Subject> element:
<element name="Subject" type="orms:anyURI"/>

5.5 Element <Score>

The <Score> element contains a string value of a reputation score defined in the namespace of the <Context> element.
type [Required]

The type attribute is a URI that identifies the the score type being declared. This value MUST be an absolute URI. This URI value is application specific, and is used by the reputation data provider to declare a score type to consumer familiar with the type identifier.

5.6 Element <Date>

The <Date> element contains a time value which specifies the dates defined in the namespace of the <Context> element. The value MUST be expressed in UTC form, as specified in Section 1.5.3, “Time Values”, and MUST NOT use fractional seconds.
The semantics of this element apply to the metadata available in the <Context> element and ...
The following schema fragment defines the <Date> element and its DateType complex type:
<element name="Date" type="orms:DateType"/>
<complexType name="DateType">
<simpleContent>
<extension base="orms:dateTime">
<attribute name="type" type="anyURI" use="required"/>
</extension>
</simpleContent>
</complexType>

6. XRD Signature

An XRD provider MAY digitally sign an XRD document in order to enable XRD consumers to verify the authenticity and integrity of the document. The [XML Signature] specification defines a general XML syntax for signing data that includes many options for flexibility. This section details constraints on these options so that XRD consumers do not have to implement the full generality of XML Signature processing.

6.1. Signing Formats and Algorithms

XRD documents MUST use enveloped signatures as defined by [XML Signature] when signing. Any signature algorithm defined by [XML Signature] MAY be used.

6.2. References

XRD documents MUST supply a value for the xml:id attribute on the root element of the XRD being signed. The XRD's root element may or may not be the root element of the actual XML document containing the signed XRD (e.g., it might be included within another document). Signatures MUST contain a single <ds:Reference> containing a same-document reference to the xml:id attribute value of the root element of the XRD being signed. For example, if the xml:id attribute value is foo, then the URI attribute in the <ds:Reference> element MUST be #foo.

6.3. Canonicalization

XRD implementations MUST use [Exclusive Canonicalization] without comments, both in the <ds:CanonicalizationMethod> element of <ds:SignedInfo>, and as a <ds:Transform> algorithm.
Use of Exclusive Canonicalization facilitates the verification of signatures created over XRD instances when placed into a different XML context than present during signing. Note that use of this algorithm alone does not guarantee that a particular signed object can be moved from one context to another safely, nor is that a requirement of signed XRD instances in general, though it may be required by particular profiles.

6.4. Transforms

Signatures in XRD documents MUST NOT contain transforms other than the enveloped signature transform (with the identifier or the exclusive canonicalization transform (with the identifier

6.5. KeyInfo

XML Signature defines usage of the <ds:KeyInfo> element. XRD does not require the use of <ds:KeyInfo>, nor does it impose any restrictions on its use. Therefore, <ds:KeyInfo> MAY be absent.

B. Examples (Non-Normative)

Example B.1. Simple ORD Example

Example B.2. ORD ReputationBundle Example

<ReputationBundle>
<Reputation id=" rel="parent">
<Context>
<Subject>
<Score type="
<Date type="
<Date type="
</Reputation>
<Reputation id=" rel="child">
<Subject>
---whatever sub reputation data here---
</Reputation>
<Reputation id=" rel="child"/>
---only link to sub reputation document---
</ReputationBundle>