Visa's Interest in XRI

["Wachob, Gabe" <gwachob@visa.com>]

This email is long overdue. Its time that I describe why Visa is
involved in XRI. I don't intend to argue XRI's supremacy over other
identifier schemes - my intent is merely to illustrate why Visa is
motivated to work on XRI.  I hope this helps other organizations or
individuals understand why XRI might be interesting to them. 

VISA PERSPECTIVE ON IDENTIFIERS
===============================

Visa has very real and *specific* needs for identifier systems. By using
Credit Card numbers (we call them Personal Account Numbers - "PANs") as
a way to talk about the Visa ecosystem around identifiers, I hope to
illustrate our motivations and the way we use identifiers. I think this
may be a perspective that others don't have. These are not bedrock
principles (and may in fact change over time) but demonstrate the
mindset that we have to use when thinking about identifiers:

1) HIERARCHICAL and DELEGATED: PANs are assigned hierarchically and
issuance/control of actual individual PANs is delegated to member
issuing banks. Visa is a distributed organization that involves the
delegation and coordination of activities between a corporate center,
regional offices and Visa member banks. Visa controls the *root* of the
namespace for PANs issued by Visa members. MasterCard controls the root
of the namespace for PANs issued by MasterCard members. American Express
controls its own namespace for PANs, etc. This delegation is itself set
up by ISO. 

2) CONTROLLED DELEGATION: Visa controls the "delegation policies" for
PANs. All Visa PANs start with 4, but beyond that, PANs are delegated to
Visa Issuing Member banks. Even so, the way that banks delegate
identifier spaces are still controlled, to some extent, by Visa. All of
the delegation happens through the first 6 digits (the "BIN") of the
PAN. Visa tightly controls this delegation and the policies around it.
Beyond the 6 digits, banks are free to manage the identifiers.  

3) STRUCTURED IDENTIFIERS: Visa identifiers are semantically meaningful,
within prescribed limits (e.g. identifiers are "constructed" and
"deconstructed" by extracting, for example, the BIN (bank identifier)
from the credit card number). 

4) 3rd PARTY RELIANCE ON STRUCTURE: The structure of PANs is relied upon
by a number of parties, many of whom are not under the direct control of
Visa. For example, the knowledge that Visa PANs start with 4 and
MasterCard PANs start with 5 is a well known fact and many parties
(merchants, processors, etc) rely on this fact. 

5) SENSITIVITY OF IDENTIFIERS: Most PANs are "sensitive" in that mere
knowledge of these identifiers can (along with other info) be valuable
to unauthorized parties. Thus, the way they are used is very strictly
controlled by Visa and parties associated with Visa have to adhere to
strict policies about handling these identifiers.

6) MULTIPLE USES: Our identifiers are used both within our processing
network as well as in a variety of other systems involved in the
end-to-end processing of payment transactions. Each of these systems
handles PANs and has specific requirements for the use of the
identifiers within their function in payment. 

7) TRUSTABLE AND AUDITABLE: Any distributed resolution scheme for PANs
has to be trustable and auditable. Visa payment is about liability
transfer more than anything else and so each step must be verifiable
(this is not to say that each individual transaction is actually
verified in any single way.)

We believe that other communities of interest will have similar needs
and therefore believe that the XRI effort should exist as a public
standards effort. Examples of such communities might be online
marketplaces, other types of associations doing valuable electronic
business, or businesses that need identifiers that are both delegated
and trustable/verifiable/auditable. In addition, we believe that some
user-driven communities will have similar interests in forming
identifier communities that don't rely on outside parties to act as the
root of trust for identifiers used in those communities. 

ADAPTABILITY AND STITCHABILITY
==============================

We have participated in the XRI effort to end up with an identifier
scheme that reflects the motivations illustrated above. In addition, we
believe that a key driver for XRI is adaptability - i.e. requirements
for a particular community may *change over time*. For example, while a
community may want to start with closed and control its own namespaces,
it may later want to join with other communities, adopt new delegations,
or adopt new policies for name assignment. Communities mature, make
contact, and establish trust relationships with other communities
through business arrangements or simply through repeated positive
interactions with outside communities. A very static and brittle
identifier system, even if hierarchical and delegated, makes such
adaptability difficult to achieve. 

The most common adaptations in community identifier infrastructure
relate to joining or interoperating with other communities. The
following scenarios describe "federation", one of the key concepts for
XRI development. I call this process "stitching together" two or more
identifier communities after they've already been deployed:

1) PAIRWISE FEDERATION: Communities of interest may want to have their
(as yet private) identifiers used by others. XRI provides a mechanism to
allow one community of interest to identify another community and then
unambiguously use identifiers in that second community of interest. Such
"federation" may occur between business partners or members of distinct
organizations with members that need to interact (such as disparate IM
systems that wish to interoperate and bring their user communities
together). Furthermore, such federation may happen *after* deployment of
the private identifier spaces - such federation need not be anticipated
from day one. 

2) ASSOCIATION-BASED FEDERATION: Two private communities may want to
join (federate) under a parent association (which is itself identified).
Each community would recognize that same parent association. That parent
association would then refer to each of the federated communities
through a distinct identifier. Thus, each of the distinct communities is
now known not only to itself, but also known relative to the parent
association. Identifiers within each of the private communities can
therefore constructed by appending the identifier for the parent
association with the identifier for the federated private community, and
then finally the identifier assigned by the private community. This
concept results in a form of "delegation" whereby each community's
identifiers are still controlled by the community, yet are still unique
and resolvable to those who recognize the new parent association.

A very important implication of this "stitchable" identifier system is
that it becomes a requirement that a resource may be identifiable
through any delegation path - because there may not be an absolute root
for identifiers. For example, one user community may know a resource by
one identifier, and another community may know it by another identifier.
This may be for historical, semantic, political, or privacy reasons.
Additionally, if two communities refer to a 3rd community by different
names, identifiers assigned by that 3rd community should still be
resolved *by that 3rd community* (i.e. resolution should continue to be
delegated to the community that assigned them). 

This reflects the reality of a loosely coupled world. Instead of trying
to design or argue this fact away, XRI recognizes, embraces, and makes
use of such an identifier architecture - while still providing trust,
auditability, and security in that resolution, if so desired.  
 

__________________________________________________ 
gwachob@visa.com 
Chief Systems Architect 
Technical Innovation and Standards Management
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817