Re: [XRI] ARK comparison

Marty,

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).

Regards

Stuart
--

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:/1.2.3.4. 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 matches.
>  
> 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 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.
>  
> Regards
>  
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks 
> RG12 1HN
> Registered No: 690597 England
>
>      
>

Received on Friday, 18 July 2008 18:11:02 UTC