ContactServiceSpecs - XDI.ORG Wiki

I-Name Contact Service Specifications

Introduction
Contact Service 1.x Specifications

Working Drafts
Referenced Specifications
Service Type XRI

Use Cases

Actors
Preconditions
Basic Use Case
Reply Variants

Direct Email Reply
Anonymous Email Reply
Complaint

New Requirements

Multiple Contact Pages Per Account
Contact Page Presentation

HTML Tag Support
I-Name Display
I-Name Address Bar
Contact Reputation and Third Party Reputation Link

Search Optimization

Standardized Search Metadata
Search Engine Feeds

Configuration

I-Name Selection
Contact Request Message
Confirmation Message
Reputation Filter
Authenticated Third-Party RSP Link

Contact Request Messages

Complaint Link
Bounce Processing

Auto-Setup

1. Introduction

This is the home page for community development of the specifications for a standard XRI-based contact service. This service allows Receivers to maintain a public Web address that allows legitimate new contacts to reach them while not allowing spam. It combines HTML forms (Web searchable using standard keywords) with authentication using I-Name Single Sign-On (ISSO – see IssoSpecs) or email.

2. Contact Service 1.x Specifications

2.1. Working Drafts

Working Drafts will be posted here. Please post feedback on the current draft to this page.

Current Draft: Contact Service Working Draft 01: icontactV1.0
Previous Draft: Contact Service Working Draft 00: ibroker_PCS.doc

Note: Working Draft 01 will be superceded with a new working draft incorporating the new features described below. Subscribe to this wiki page for updates as these specifications are completed.

2.2. Referenced Specifications

The I-Name Contact Service 1.x specs are based on:

The XRI 2.0 Committee Draft specifications currently in public review at OASIS. See the XRI TC home page for links to these specifications (including XRI Syntax 2.0, XRI Resolution 2.0, and XRI Metadata 2.0.)
The XDI.ORG Global Services 1.0 Specifications (GSS) at http://gss.xdi.org, and in particular the Public Authority policies and specifications (see http://gss.xdi.org/moin.cgi/GssPolicies_2fPublicAuthorityPolicies and http://gss.xdi.org/moin.cgi/GssOpSpecs.)
The IssoSpecs.

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

XRI 2.0 Resolution Specification for more details.

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

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

3. Use Cases

Following is the basic Contact Service use case.

3.1. Actors

Sender (user seeking to contact the Receiver).
Receiver (I-Name authority that controls the Contact Page)
I-Broker
(Optional) Search Engine

3.2. Preconditions

Receiver has 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").
I-Broker offers Contact Service and Receiver is authorized to use it.
Receiver has configured and activated a Contact Page.
(Optional) Contact Page has been indexed by a Search Engine.

3.3. Basic Use Case

Sender navigates to Contact Page. Note the four basic options for doing this:

Sender clicks a link containing a contact page address (the HTTP address of an XRI public resolver plus the Receiver's i-name, i.e., http://public.xdi.org/=example.name).
Sender does a search for a Contact Page via a Search Engine.
Sender types contact page address directly into a browser address bar.
Sender types i-name by itself directly into I-Name Search Box (application that performs XRI resolution).

Sender enters requested input data into Contact Page form.
I-Broker verifies Sender (either using ISSO or email authentication).
I-Broker sends Contact Request email to Receiver at preferred email address.
Based on the data submitted, the Receiver either ignores the Contact Request, replies as desired, or submits a Complaint (see Reply Variants below).

3.4. Reply Variants

3.4.1. Direct Email Reply

In this variant, the Sender submitted his/her email address and the Contact Request contains the Sender's email address as the SMTP Reply-To address, so the Receiver can just reply directly from his/her email client (thereby sharing his/her email address.)

3.4.2. Anonymous Email Reply

In this variant, the Sender submitted his/her email address and the Contact Request contains the Sender's email address as the SMTP Reply-To address, however the Receiver wants to reply without revealing his/her email address. There are two sub-variants:

Receiver wants to reply anonymously via his own I-Broker. In this case the Receiver clicks an Anonymous Reply Link in the Contact Request to send a reply via an HTML form at Receiver's I-Broker. This option maintains a "thread" of
Sender included his/her i-name, and the Contact Request contains Sender's Contact Page Link. Receiver replies by clicking the link and entering the message into Sender's Contact Page without revealing his/her email address.

3.4.3. Complaint

The Contact Request contains a Complaint Link to a Complaint Form at the Sender's I-Broker. The Receiver files a Complaint using this form and authenticates the Complaint using ISSO (see IssoSpecs).

4. New Requirements

This section describes the new features or feature enhancements that are incremental to Working Draft 01 (see the ISSO 1.x Specifications above). A new Working Draft will be issued once these features have been scoped and designed.

4.1. Multiple Contact Pages Per Account

If a Receiver has more than one i-name, Receiver MUST be able to activate and configure a different Contact Page for each i-name, and MUST be able to select which i-name(s) resolve to which Contact Pages. An i-name is not required to resolve to any Contact Page, however it MUST NOT resolve to more than one Contact Page. For example, if Receiver has 3 i-names, they could choose to have:

All three resolve to one Contact Page.
Two resolve to Contact Page A, and one resolve to Contact Page B.
All three resolve to three different Contact Pages.

Each Contact Page MUST be able to be configured separately.
Receiver MUST be able to configure the email subject line prefix of the Contact Request Message that will be produced by each Contact Page. The default email subject line prefix should one of Receiver's i-names for that Contact Page.

4.2. Contact Page Presentation

4.2.1. HTML Tag Support

Receiver’s self-description SHOULD support basic HTML formatting and link tags. It is not necessary to support any HTML tags that could be used in a cross-scripting attack.

4.2.2. I-Name Display

I-Broker MUST display the i-names selected by Receiver on the Contact Page for those i-names.

4.2.3. I-Name Address Bar

I-Brokers SHOULD offer an i-name address bar as part of the "i-broker frame" surrounding a contact page. This makes it easy for Senders to enter an i-name to navigate to a different contact pages (for example, if after a search the current contact page does not represent their intended contact.)

Proposed design:

The address bar would accept an i-name string, resolve the XRI, and redirect to the target URI using Redirection Service (see RedirectionServiceSpecs.)

4.2.4. Contact Reputation and Third Party Reputation Link

The contact page MUST automatically display the Receiver’s third party reputation link if that configuration option is selected by the Receiver.
OPEN ISSUE: Should I-Brokers be required to display the Receiver's Contact Reputation Score on Receiver's Contact Page?

4.3. Search Optimization

4.3.1. Standardized Search Metadata

XDI.ORG MUST specify the standard search terms that are added by all i-brokers to all contact pages to help establish relevance (such as +contact).

Aman, please suggest any specific terms here.

4.3.2. Search Engine Feeds

I-Brokers SHOULD automatically feed contact pages to search engines and/or otherwise make them very accessible to spiders.

4.4. Configuration

4.4.1. I-Name Selection

Receiver MUST be able to select the i-names that will resolve (and be displayed on) any Contact Page. See "Multiple Contact Pages Per Account" above.

4.4.2. Contact Request Message

I-Brokers SHOULD put all "boilerplate" text about Contact Service and user instructions about Contact Request Messages at the bottom of a Contact Request Message.
Receiver SHOULD have the option to eliminate this boilerplate text inserted into a Contact Request Message by their I-Broker. (Note this does not include eliminating the Sender's Contact Page Link or the Complaint Link, both of which MUST automatically appended at the bottom of the contact request if the Sender submitted an i-name.)

4.4.3. Confirmation Message

Receiver SHOULD be able to change the text of the confirmation message that Sender receives after the Sender has successfully authenticated the Contact Request. (In particular Receivers may wish to say how they will be contacted and what the expected response time will be.)

4.4.4. Reputation Filter

Receiver MUST be able to set the threshold Contact Reputation Score below which I-Broker will automatically reject Contact Requests.

4.4.5. Authenticated Third-Party RSP Link

Receiver MUST be able to control automatic display of his/her authenticated third-party reputation service provider link. See ReputationServiceSpecs.

4.5. Contact Request Messages

4.5.1. Complaint Link

The contact request message MUST include a Complaint Link generated by Receiver's I-Broker. See ReputationServiceSpecs.
This link MUST be keyed to the authenticated XRI of the Sender and the XRI of the Contact Request Message.

4.5.2. Bounce Processing

If Sender submits an email address, and the Contact Request Message bounces back to the I-Broker, the I-Broker SHOULD send a bounce notification to Sender.

4.6. Auto-Setup

XDI.ORG MUST specify whether contact service should be configured and activated automatically for new i-name registrants.

OPEN ISSUE: The current consensus is that it should, with the first registered i-name automatically receiving a default Contact Page, however if Receiver has not provided an email address to his/her I-Broker, any Contact Request Messages would only be received when Receiver logs in.