RE: [xri] 1) XRD Subject matching & 2) host meta URI

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, August 24, 2009 9:54 PM
> To: 'XRI TC'
> Subject: [xri] 1) XRD Subject matching & 2) host meta URI
> 
> I just had a long talk with John Bradley about both of these subjects
> (and
> their relationship).
> 
> We came out with 2 key points:
> 
> 1) Do we really need #begins-with subject matching? Does anyone
> actually
> have a use case for it? (Your own use case, not someone else's.)
> 
> John pointed out that if even a single resource within the subject set
> scope
> needs its own XRD, then all resources within the subject set scope will
> need
> their own XRDs, because we don't have a way of expressing, "all
> resources in
> the example.com domain EXCEPT example.com/exception".
> 
> So who has a use case that requires subject sets? If not, let's drop
> it, and
> do away with the match attribute.

Other than host-meta, which Dirk has strong objection to use in this way, no.

> 2) Does the subject of a host-meta XRD just need a way to indicate that
> the
> subject is not a concrete URI, but the abstract concept of the host for
> that
> URI?

No, it just needs to be something that clients can verify that:

1. This is a host-meta file (that is, it was created for the explicit purpose of being a host-meta file, not any other XRD from the same host).
2. This host-meta file describes a specific host.
3. It contains an authority component that can be compared to the certificate used to sign it.

> If so, let's just specify that for a host meta URI, you add a blank
> hash
> tag. Example:
> 
> 	http://example.com	<== Concrete subject
> 	http://example.com#	<== Abstract host meta subject
> 
> It's a simple solution that happens to be consistent with the SemWeb
> but
> doesn't require any SemWeb baggage.

It fails #1 because adding # at the end of the domain root resource URI is not in any way an acceptable way to refer to a host. It is also going to confuse a lot of people and host-meta should not need to give them a tutorial in semantic web URI fragments (which I personally don't like).

Host-meta does not need a Subject. It just needs a place to say "I'm a host-meta file for this host (and port)" and it needs to say how you need to compare this string with the certificate. What we are missing, as my previous email ('Subject and authority') indicated, is a place to put trust related subjects that are not URIs.

For host-meta, it would probably look something like (using <Authority> as a placeholder):

<Authority>host:example.com:80</Authority>

The problem with putting this inside <Subject> is that it either violates the URI syntax or it uses made-up schemes. In theory this Subject will validate (XML wise) because XML parsers do not check IANA registry for URI schemes.

At this point, if we keep Subject as a URI but allow it to contain any string that comply with the URI syntax regardless of it being a valid URI (i.e. with a registered scheme), work for me.

EHL