RE: [XRI] ARK comparison

Hi Stuart (& All),
When we can live with certainty, why would we make it a design objective to
live with possibility and ambiguity?
The ARK spec ( says the
Name Mapping Hostport (the part before the path) is optional and that the
following are all valid ARKs:
How would we represent the third example as a URI? I'm not sure, but perhaps
it would be http:///ark:/12025/654xz321. To where would I make the http:
request with an accept: application/xrds+xml?
How would the pattern of using a path indicator work for OID or other types
of identifiers for which we commonly use URN? Perhaps http:///oid:/
To where would I make the http: request with an accept: application/xrds+xml
to determine if it's certainly a OID or just possibly a OID.
There's a second reason I argue against relying on some response to a query
to figure out how to treat the URI. I think it's fine for determining how to
treat the actual resource, but not for how to treat the URI itself. 
Let's say you authenticate to Boeing with a SAML assertion including your
distinguishedName (DN) identifier. Maybe it looks something like "cn=stuart,
dc=hp, dc=com" (with spaces, commas, and lowercase). But in Boeing's
directory (where we have to look to find out if you're allowed access to
Boeing resources), we have your identifier stored as
"CN=Stuart;DC=HP;DC=COM" (without spaces, with semi-colons, mixed case). How
would the matching software know if they match? The matching software would
have to be informed to use DN matching rules. 
So let's try using the path indicator approach to declare that it's a DN
(I'll ignore percent encoding for these examples for legibility sake). The
identifier in the assertion now looks like,
<, dc=hp, dc=com> dc=hp, dc=com. So now my
matching software has to query to find out if it's really a DN or just
possibly a DN. If for some reason that query fails, or returns no helpfull
information, your identifier won't be able to be matched in the Boeing
directory, and you won't be allowed to access Boeing resources. Any kind of
network/maintenance/other outage drives up false negative matches.; CISSP 
Associate Technical Fellow - Cyber Identity Specialist 
Information Security - Technical Controls 
(206) 679-5933 


From: Williams, Stuart (HP Labs, Bristol) [] 
Sent: Friday, July 18, 2008 3:41 AM
To: John Bradley; Erik Hetzner
Subject: RE: [XRI] ARK comparison 

Hello John,
I think that the nub of the question that you and other comes down to:
"How can I look at some arbitary URI/IRI and know just by looking at it,
that it is an XRI (or an ARK or whatever...)" ie. you are looking for a
syntact marker or a pattern match that will assure you that the a given
identifier string is intentionally of a particular category rather that just
one that looks like it is. A world of certainty rather than possibility
(from inspection of the identifier alone).
1) A URI scheme definition can give that certainty.
2) In some limited way, on the basis of policy published by a domain
authority - eg for, matching something like ^[=@$(]
could give certainty.
3) For an existing scheme, matching lower down (further left) in the
authority field or somewhere down the path lead only to possibility, not
So... can we find a way of living with possibility rather than certainty? 
eg. if an identifier looked and smelled like an XRI would an attempt to use
it as an XRI yield a determination one way or the other (at least at the
time of asking) - ie making an http request with an accept:
application/xrds+xml  would yield either  an XRDS (or maybe XRD - haven't
really grokked the difference yet) representation, a 404, a redirection or
something else. Only in the first case (I think) has it been demonstrated
that the URI can be used as an XRI.
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12
Registered No: 690597 England


Received on Friday, 18 July 2008 15:45:54 UTC