W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

RE: Boeing XRI Use Cases

From: Schleiff, Marty <marty.schleiff@boeing.com>
Date: Wed, 16 Jul 2008 23:14:09 -0700
Message-ID: <173625C7A199934BA40AAA1CD296D2B54DE0B3@XCH-NW-03P.nw.nos.boeing.com>
To: "Schleiff, Marty" <marty.schleiff@boeing.com>, "John Bradley" <john.bradley@wingaa.com>, "Erik Hetzner" <erik.hetzner@ucop.edu>
Cc: "Paul Prescod" <paul@prescod.net>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, "Mark Baker" <distobj@acm.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, <www-tag@w3.org>
I've been informed that a couple things in my prior message (below) were
confusing. I'll try to clear them up.
 
First, my example had a slight syntax error (the first asterisk should have
been a slash). 
 
Second, I reused the authority segment ("ark.example.org") from Erik's
example, and some people though the "ark" was significant to the discussion.
I'll just use "example.org" in the new example.
 
Third, I mentioned ARK's acronym "NAAN" without defining it. It stands for
Name Assigning Authority Number. It's the part before the slash ("12345" in
the example).
 
Here's the corrected example of an ARK expressed in HXRI:
 
    http://xri.net/example.org/($ark*12345%2Fabcdefg)
 
A fourth possible point of confusion is that I took liberty to drop parts of
the ARK syntax that I thought could be better served by XRI syntax. In fact
the complete ARK syntax (see http://www.cdlib.org/inside/diglib/ark/) could
be retained when expressing an ARK in an HXRI, something like the following
(it gets pretty ugly having to percent encode all the slashes):
 
    http://xri.net/$ark*(http:%2F%2Fexample.org%2Fark:%2F12345%2Fabcdefg)
 
ARK proponents could pick their preferred format (there are probably other
options as well) and specify the definition of "$ark" so that everyone
understands the intended meaning and syntax constraints. 
 
I hope ARK proponents will be interested enough to explore use of XRI to
represent ARKs.
 
Marty.Schleiff@boeing.com; CISSP 
Associate Technical Fellow - Cyber Identity Specialist 
Information Security - Technical Controls 
(206) 679-5933 
 

  _____  

From: Schleiff, Marty 
Sent: Wednesday, July 16, 2008 6:08 PM
To: John Bradley; Erik Hetzner
Cc: Paul Prescod; Henry S. Thompson; Mark Baker; Booth, David (HP Software -
Boston); www-tag@w3.org
Subject: RE: Boeing XRI Use Cases


Hi John & Erik (& All),
 
I don't like the pattern ARK uses (for reasons already mentioned), and I'm
not in favor of using the same pattern for XRI (for the same reasons already
mentioned). But I do think it would be interesting to look at expressing
ARKs within XRI.
 
I think the problems Erik mentioned align very well with one of the Boeing
XRI Use Cases (see  <http://wiki.oasis-open.org/xri/BoeingXriUseCases>
http://wiki.oasis-open.org/xri/BoeingXriUseCases). Look at the fifth one:
"Multiple Identity Providers (for the same entity)". 
 
Henry said the metadata for a particular object is intended to be the same
no matter which sponsoring organization is asked. Although the Boeing use
case describes different metadata being returned by each identity provider,
certain metadata items could be intended to carry the same information about
a resource no matter which identity provider is asked. 
 
An ARK expressed in HXRI that is resolvable now might look like this
(unfortunately the delimiter between the NAAN and the name is a slash, which
would have to be percent encoded as %2F in an XRI cross reference):
 
     http://xri.net/ark.example.org*($ark*12345%2Fabcdefg)
<http://xri.net/ark.example.org*($ark*12345%2Fabcdefg> 
 
This example assumes that "$ark" gets defined in the XRI "$" dictionary.
This is an unambiguous way for the minter to declare (and for the relying
party to know) that "12345/abcdefg" is an ARK. It would look a little
cleaner if the delimiter between the NAAN and the name were some other
character that wouldn't require percent encoding. The power of using XRI for
this is that it can work for nearly(?) any type of identifier.

Marty.Schleiff@boeing.com; CISSP 
Associate Technical Fellow - Cyber Identity Specialist 
Information Security - Technical Controls 
(206) 679-5933 

 

Received on Thursday, 17 July 2008 06:15:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC