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

RE: [XRI] ARK comparison

From: Schleiff, Marty <marty.schleiff@boeing.com>
Date: Fri, 18 Jul 2008 11:58:56 -0700
Message-ID: <173625C7A199934BA40AAA1CD296D2B5540360@XCH-NW-03P.nw.nos.boeing.com>
To: "Stuart Williams" <skw@hp.com>
Cc: "John Bradley" <john.bradley@wingaa.com>, "Erik Hetzner" <erik.hetzner@ucop.edu>, <www-tag@w3.org>

Hi Stuart (& All),

I thought my examples did answer the questions, at least that's what I
was trying to do. So here's the direct answers:

1) Yes. I argue that this is a requirement for any identifier, not just
XRI -- at least for use cases where there is no surrounding context to
indicate the type of identifier.

2) No.

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

-----Original Message-----
From: Stuart Williams [mailto:skw@hp.com] 
Sent: Friday, July 18, 2008 11:10 AM
To: Schleiff, Marty
Cc: John Bradley; Erik Hetzner; www-tag@w3.org
Subject: Re: [XRI] ARK comparison


I tried to ask a general question in a general way. You seem to have
dived down into a detailed hypothetical and somehow not answered the
question... so I'll ask it again.

1) Is it an XRI requirement that it is possible to definitively
recognise if an identifier is an XRI or not merely by inspecting the
identifier (and *nothing* else).
2) Can XRI requirements be met with a strategy that can determine that a
'candidate' XRI is infact an XRI by trying to resolve it as an XRI (and
the resolution process giving a definitive answer).



Schleiff, Marty wrote:
> 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 (http://www.cdlib.org/inside/diglib/ark/arkspec.html)
> says the Name Mapping Hostport (the part before the path) is optional 
> and that the following are all valid ARKs:
>    http://loc.gov/ark:/12025/654xz321
>    http://rutgers.edu/ark:/12025/654xz321
>    ark:/12025/654xz321
> 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 
> http://hp.com/dn:/cn=stuart, dc=hp, dc=com 
> <http://hp.com/dn:/cn=stuart,%20dc=hp,%20dc=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
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist Information 
> Security - Technical Controls
> (206) 679-5933
> ----------------------------------------------------------------------
> --
> *From:* Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com]
> *Sent:* Friday, July 18, 2008 3:41 AM
> *To:* John Bradley; Erik Hetzner
> *Cc:* www-tag@w3.org
> *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 xri.net, matching something like 
> ^http://xri.net/[=@$(]  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 certainty.
> So... can we find a way of living with possibility rather than
> 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.
> Regards
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN
> Registered No: 690597 England
Received on Friday, 18 July 2008 18:59:57 UTC

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