RE: [xri] Visa's Interest in XRI

["Ajay Madhok" <Ajay.madhok@amsoft.net>]

Hi Gabe,

That's (replace RDF with XRI) very well put indeed! And is consistent with
the underlying vision of loose coupling, and everything distributed. In
fact, our work in SOA demonstrates that a XRI like framework is a
pre-requisite for any loosely coupled, distributed and discoverable
architecture.

Your articulation of Visa's interest in XRIs and expectations from an
Identifier framework is very compelling. I am very encouraged that VISa is
indeed thinking about Federation. 

Along the same lines, you may want to illustrate XRI's value proposition as
a  Universal Identifier somewhere -- for example under your Item 6 (Multiple
Uses). Would it not be nice that a Visa PAN can also be used to get credit
for my United Miles and my Macy's spend?
 
Cheers,

=Ajay

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Friday, January 06, 2006 7:23 AM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Visa's Interest in XRI

BTW, the concept of stitching came from a passionate defense of the
Semantic Web by Timothy Falconer in a recent blog entry here:

http://bigfractaltangle.com/archive/2006/01/02.jsp

"The Semantic Web approach is LOOSE, not normalized. The beauty of RDF
and OWL is that you can take messy incompatible schemas and interconnect
them after the fact, giving structure to what was once incompatible. The
semweb community has always taken a "build them as islands, then stitch
them together" approach, as they really do understand the need for
looseness."

Replace "Semantic Web" (and RDF/OWL) with "XRI" and he would be making
my point about an identifier architecture.

   -Gabe

> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> Sent: Thursday, January 05, 2006 5:42 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Visa's Interest in XRI
> 
> 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 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php