- From: Schleiff, Marty <marty.schleiff@boeing.com>
- Date: Fri, 18 Jul 2008 08:44:44 -0700
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "John Bradley" <john.bradley@wingaa.com>, "Erik Hetzner" <erik.hetzner@ucop.edu>
- Cc: <www-tag@w3.org>
- Message-ID: <173625C7A199934BA40AAA1CD296D2B54DE76E@XCH-NW-03P.nw.nos.boeing.com>
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, <http://hp.com/dn:/cn=stuart, 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. 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 15:45:54 UTC