Boeing Use Cases for XRI

Fully Qualified Identifiers:

Boeing uses the XRI (eXtensble Resource Identifier) framework to fully qualify identifiers and avoid name collisions between employee IDs, application IDs, device IDs, IDs received in SAML (Security Assertion Markup Language) assertions from business partners, etc. By combining such base IDs with an identifier of their respective naming authority (or perhaps a hierarchical representation of the pertinent naming authorities) naming collisions are avoided.

The http: URI (Uniform Resource Identifier) scheme could be used to envelop such base identifiers in a hierarchical naming scheme; however, we selected XRI (eXtensible Resource Identifier) because of its syntactic metadata, its ability to express one identifier in the context of another, and for its resolution capabilities.

Identifier Types in Directories:

Entries in our enterprise directory generally include several identifiers in various formats with different matching rules. For example to support federation with our partners, entries representing non-Boeing users include a boeingMappingID containing the user’s identifier at his/her home organization that gets asserted to us in a SAML assertion. To support X.509 authentication on some of our programs, entries representing non-Boeing users include a boeingMappingDN containing the distinguishedName appearing in the user’s X.509 certificate. If some of our customer airlines adopt OpenID authentication then we may need to extend schema again with a new attribute type such as boeingMappingOpenID so we could map the non-Boeing user’s authenticated OpenID to a Boeing internal identifier. If other Boeing customers adopt Handle identifiers, we may need to extend schema yet again with boeingMappingHandle. Requirements to support other identifiers may require even more schema changes.

The XRI identifier framework enables nearly any type of identifier to be represented within an XRI. This will enable us to store all of the matching IDs in a single attribute type in our directory. Our applications would have a consistent approach to look up an identifier in our directory to find its associated attributes.

Today our Enterprise Directory Service includes XRIs for every entry representing a person, application, or device. Some Boeing applications are currently using XRI in production. Although today we only support case sensitive string values for XRI, in the future we may request directory vendors to support XRI matching rules, or we may develop a directory plug-in to enable XRI matching rule capabilities in our directory.

Identifier Metadata:

First we need to clarify that this is not the same topic as covered in the “TAG Finding on Metadata in URIs” (http://www.w3.org/2001/tag/doc/metaDataInURI-31.html), in which the metadata examples illustrate intuitive metadata that might (or might not) be meaningful to a human mind, but are in no way meaningful to software. It may be true that a person seeing http://example.org/weather/Chicago might rightly (or wrongly) assume a similar site exists with similar functionality at http://example.org/weather/Boston. However, XRI metadata is syntactic, unambiguous, and process-able by software.

More than a type of identifier, XRI is an identifier framework, enabling nearly any other identifier to be represented within the XRI framework. An XRI minter can use XRI metadata to make claims about the base identifier within the XRI to other applications. Such claims supported in XRI today include the following:

XRI metadata is an extensible namespace which allows additional claims to be defined in the future. Such claims of special interest to Boeing might include the following:

It’s true that few XRI-savvy applications exist today; however, by XRI-metadata-enabling just a single application (our directory service) we would achieve significant benefits. Further benefit might be realized by XRI-metadata-enabling databases and other software that commonly performs identifier matching.

XRI as an Alternative to distinguishedName and LDAP/X.500:

A directory entry’s supposedly global unique identifier is a distinguishedName (or DN). DNs are also commonly used in X.509 certificates as an identifier of the entity possessing the associated private key. An example DN in our enterprise directory looks like “cn=27256,ou=people,o=boeing,c=us”.

Aspects of XRI are very similar to distinguishedName. Both are intended to be globally unique based on a hierarchy of namespaces. However, because the higher layer authorities for distinguishedName don’t support resolution, anyone can deploy an LDAP directory for namespaces like “o=boeing,c=us” or “dc=boeing,dc=com”. XRIs are rooted in resolvable namespaces such as DNS, “@”, and “=”. So even if some non-Boeing entity started minting XRIs like “@boeing*fred”, or “xri://xri.boeing.com/fred”, resolution of the XRI would be directed to Boeing, where Boeing can authoritatively respond about identifiers under Boeing namespaces.

Attempts to resolve DNs are problematic, because the server that hosts the directory must be known and is not inherent in the DN. By contrast, XRIs are inherently resolvable.

LDAP and X.500 have been around for a long time (Boeing deployed production LDAP and X.500 services 15 years ago). Yet even after 15 years, relatively few organizations allow inter-enterprise LDAP or X.500 operations. We have hopes that XRI Resolution will eventually provide a more effective means of inter-enterprise identifier resolution than is practical via LDAP or X.500 today.

When our business partners authenticate to Boeing using X.509 certificates, the identifier in the certificate that represents the user is a distinguishedName. Because we can’t effectively determine which directory (at the partner company) to query (even if they have made such a directory accessible), we have to train our applications to do lookups of other companies’ distinguished names in our own directory (using the boeingMappingDN described above), and we have to maintain shadow accounts for the non-Boeing people in our directories. Keeping non-Boeing identity data current in our directories is a significant and expensive effort for us.

We’ve been exploring use of XRI in X.509 certificates, and for some types of Boeing-issued X.509 certificates we now put an XRI representing the subject into the certificate’s subjectAltName. We hope this approach of including fully resolvable XRIs in certificates eventually becomes a recognized best practice among our trading partners.

Multiple Identity Providers (for the same entity):

An attractive aspect of XRI is that one identifier can be put in the context of another identifier, enabling us to support use cases such as the following.

Consider a company registered as “example” in the XRI @ namespace. The resulting XRI representing the company would be “@example”. A user at that company might have an XRI like “@example*bob”. The user’s home company is his identity provider, so if we resolved the XRI we would get back an XRDS provided by the user’s company.

Rather than create a new identifier for the user, we could put his existing identifier into a Boeing context as follows: “@boeing*(@example*bob)”. If someone resolved this XRI they would get back an XRDS describing the same user, but the XRDS would be provided by Boeing, and it might have different service points and data than an XRDS provided by the user’s home company. Both XRIs [“@example* bob” and “@boeing*(@example*bob)”] represent the same user, but in different contexts (i.e., in the context of his own company, or in a Boeing context).

To perform certain tasks in airplane manufacture/maintenance, regulations may require the workers to have certain training and certificates. Let’s imagine the user’s home company sends him to that special type of training at some organization that has registered an XRI of “trainer” in the XRI @ namespace.

When the user browses to a Boeing Web site with a SAML identity assertion including the user’s XRI, Boeing could conceivably request resolution of “@trainer*(@example*bob)” to obtain an XRDS about “@example*bob” from the perspective of the training company. The XRDS might include service points and data (e.g., certifications) different than an XRDS provided by the user’s home company.

Note: Although this use case included an XRI for the user’s identifier at his home company, other types of identifiers (DNs, email addresses, OpenIDs, OIDs, GUIDs, etc.) could have been used instead.

Resolution for Unresolvable Identifiers:

Many types of identifiers (e.g., OID, GUID, HIT) have no specified resolution mechanism. By expressing such identifiers in an XRI, resolution via XRI mechanisms can be supported.

For example Boeing has issued the OID 1.3.6.1.4.1.73.15.3.5. Even enveloping the OID in a URI (e.g., “urn:oid:1.3.6.1.4.1.73.15.3.5”) doesn’t enable it to be programmatically resolved. If you wanted to resolve it today, you would have to do it manually, perhaps beginning at IANA (http://www.iana.org/assignments/enterprise-numbers). You could learn that 1.3.6.1.4.1.73 represents Boeing, and see a contact name and email address (BTW, we have 4 people with that name, and the email address no longer works). If/when you find the correct person, he/she might be able to help you locate someone who might know what the full OID represents. (BTW, it represents a Certificate Policy, so it could be important to other organizations that do policy mapping between organizations).

The resolution job would be much easier by enveloping the OID within a Boeing XRI perhaps as follows: “@boeing*(urn:oid:1.3.6.1.4.1.73.15.3.5)”. XRI-savvy software would ask “@boeing” about “(urn:oid:1.3.6.1.4.1.73.15.3.5)” and receive in response an XRDS describing the named resource.

Boeing has been a key contributor to Secure Mobile Architecture (see http://www.opengroup.org/mmf/arch/) which uses HIT identifiers. To make HIT identifiers resolvable, we plan to envelop them within XRIs.

BoeingXriUseCases (last edited 2009-08-12 18:07:21 by localhost)