Re: [XRI] ARK comparison

Hello Marty,

Schleiff, Marty wrote:
> Hi Stuart (& All),
>
> I thought my examples did answer the questions,
My apologies... yes you did... I didn't see that for detail that was in 
the first few para's which seemed to be headed in a different direction.
>  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.
>   
Ok... you position is clear, which was the purpose of my question - that 
being able to tell just by looking is an important requirement from your 
pov.

David and John seem to have been working in that direction - where do 
you stand wrt to where the seem to have got in David's most recent 
message [1]

[1] http://lists.w3.org/Archives/Public/www-tag/2008Jul/0093

More below.
> 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
>
> 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?
>>     
Me neither, though in some sense I am equally at a loss wrt to where I 
would send a similar request for:

    =@plano*jbradley or @!2928.81E8.6160.C47D!0000.0000.3B9A.CA01

(ok... prepend http://xri.net/ and ask there.... but that's only because 
I looked at the and the look like XRI (or i-names) but I can't be sure 
until I try them as such).

>> 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.
>>     
Ok... whilst I'm getting the gist of this and I understand a bit (not a 
lot) about DNs, I'm not sure that I see the real differencs in the 
scenarios that you pitch against each other. If you are identifying me 
by DN and that's your key for me, and you gave an identifier that looks 
to you like it plausibly embeds a dn because it carries the dn: marker 
that you trigger off - then you extract the DN and  do the comparison - 
if I'm sending lower case with spaces and you're storing  mixed case 
without spaces that DN comparison problem exists  whichever way you look 
at it.
>> Marty.Schleiff@boeing.com; CISSP
>> Associate Technical Fellow - Cyber Identity Specialist Information
>> Security - Technical Controls
>> (206) 679-5933
>>     
BTW: lest you misunderstand me... I'm not advocating the use of inpath 
or authority markers. I was wanting to understand what you (or John) 
needed to know with certainty just from looking at an identifier - no 
other interactions with it or with infrastructure.

Stuart
--

Received on Friday, 18 July 2008 21:25:39 UTC