• BasicTerminology

Definitions

based on GssDefinitions (and see also: MarketVocabulary)

XRI

An eXtensible Resource Identifier as defined by the XRI Specifications. XRIs include any type of an I-Name or I-Number, or any combination of these types. See the InameInumberTechFaq.

I-Name

A reassignable XRI as defined by the XRI Specifications. I-names are intended to be human-memorable/meaningful and therefore generally instantiated through human action.

I-Number

A persistent XRI as defined by the XRI Specifications. I-numbers are intended to always indicate the same resource(s), or if that resource ceases to exist, the i-number is retired, never reassigned. Designed to be machine generated, and therefore not particularly human-memorable/meaningful.

XDI

XRI Data Interchange as defined by the XDI Specifications. Exchange of electronic data in XML format addressed by XRIs and gated by i-brokers.

Services to support XRI technology

These four services are logically separate by design, and communicate with each other by means of various network protocols, even if they are co-located in a particular instance.

Identity Authenticator (IDA)

• where the user's authentication credentials (e.g., password) are stored
• as a server, returns assertions relating to a i-name or i-number

• note: other projects call this the IDP or "Identity Provider." It is our opinion that the only person who can provide you with your identity is you, so we don't presume to provide you with one. But we will authenticate your identity tokens for you.

Registry

a data store of i-names and associated i-numbers. A registry is identified by an i-name/i-number in a delegator registry. The top level registry in this chain, known as a global registry, must be known a priori by the system's users. A registry must provide two interfaces:

1. Registry Server - registers i-names and their associated metadata, assuring the uniqueness of the i-name within the registry's namespace.
   1. Upon registration of an i-name, the registry either associates an existing i-number with the new i-name, or generates a new i-number to associate with it, or potentially both, depending on the requirements of the registrar. b. Additionally, there are three classes of metadata that the registry must store and associate with each i-name:
      1. zero or more XRI authority (XRIA) pointers. Any i-name may potentially delegate its authority, or in other words, any i-name may also represent a registry. XRIAs point to the registry delegated by the i-name in question. Each i-name may delegate to exactly one registry, to maintain uniqueness of that namespace, although the delegated registry may have more than one form of access, and therefore more than one XRIA. In the current design XRIAs consist of HTTP(S) URIs.
      2. zero or more Service pointers - URIs or other pointers where i-broker and i-broker mediated XDI services may be accessed for the i-name in question.
      3. one or more authorization tokens - password, public key or other token by which authorization to perform updates on the i-name metadata may be obtained on behalf of the i-name holder. (N.B. The registrar(s) may also perform update/delete data on i-names if authorized to do so.)
2. XRI Authority Server (resolver server) - answers i-name and i-number resolution requests. A resolution request, currently in the form of a HTTP(S) GET, is answered with an XRI Descriptor (XRID). An XRID is an XML format described in the XRI 2.0 Resolution document published by the XRI Technical Committee of Oasis. The XRID for a given i-name contains (some of the) metadata that the registry has stored for that i-name.

Registrar

performs create, update and delete operations on a registry, on behalf of the i-name registrant, and also potentially on behalf of the registry operator. (The registry operator is the registrant of the i-name that the registry is identified with.) Must be able to authenticate itself to the registry, and be authorized for the requested operation.

The Registrar is a special service provider with direct access to a registry and the IDA.

Dataweb Server

The Dataweb Server (see also: ArchitectureDiagrams) provides:

1. ISSO authentication (using the Service Provider Interface Toolkit, aka SPIT)

   • ISSO resolves i-names to their IDA via a Client Resolver

2. Distributed Data Services

   • data cacheing and/or storage addressed by means of XRIs, and serves that data (according to a rights path) in XDI format

   • a gate on transfer of information under the control of the user, authenticating and authorizing requesters of information, applying stored rules, negotiating and logging electronic contracts controlling the use of the given information, and serving tokens or Granovetter pointers enabling information access.

SPIT Module

• enables i-name-enabled Single Sign On (ISSO) by:

  • resolving i-names to their Local Access URI (LAU) that points at the i-name's IDA

  • queries the IDA for authentication assertions

  • consumes the assertions (via an AssertionConsumer)

• (a SPIT module is generally included as part of a Dataweb Server)

Resolver Client

• given an i-name or i-number:
  • recursively query XRI Authority Servers as described in XRI 2.0 resolution,
  • process the XRIDs that are returned
• (a Resolver Client is generally included as part of a SPIT module)

I-Broker

• "Your trusted personal Dataweb Server," or an instance of a Dataweb Server, including:

  • an IDA and Registrar,
  • one or more (Community and or Global) Registries, and
  • a suite of local services, such as a Contact Gateway Page

• Note that the term "broker" can also be applied to client-side software that performs many of the same functions as a server-side i-broker by acting as the local interface. Thus today's "browsers" may evolve into tomorrow's "brokers" and today's "cookies" may turn into tomorrows "contracts".

Comments/Feedback

Drummond

I like it - very clear.

Suggestions

Three items of feedback (feel free to erase these after they are incorporated or not):

1. It doesn't seem like "i-broker" is actually a separate service on a par with the other four, but rather a term that refers to a Dataweb Server in the context of a particular user or registrant. (Which is fine, BTW - the other terms are sufficiently precise.)
2. ISSO (or an equivalent term, such as XRI Authentication Service) doesn't appear on the list of services.
3. I think it should point out somewhere that over time, it all collapses to just Dataweb Service, i.e., registry, registrar, resolver, authentication, authorized (link contact-based) data interchange, and synchronization will all just be various functions available from Dataweb servers (just the way there are a raft of functions available from Web servers today).

Also, just a general comment, but when you add all these together into a functioning Dataweb, from a user perspective it will BE the Social Web.

Wikipedia

After Digital ID World last fall, Doc Searls strongly suggested we get all our key terms up in Wikipedia. Here's the list of what's available so far:

• http://en.wikipedia.org/wiki/I-name

• http://en.wikipedia.org/wiki/I-number

• http://en.wikipedia.org/wiki/I-broker

• http://en.wikipedia.org/wiki/Link_contract

• http://en.wikipedia.org/wiki/Trust_federation

• http://en.wikipedia.org/wiki/XRI

• http://en.wikipedia.org/wiki/XDI

• http://en.wikipedia.org/wiki/Dataweb

• http://en.wikipedia.org/wiki/Social_Web

As we make decisions about terminology here, we should reflect any changes to these terms (or new ones, like "ISSO") up there.