RE: [xri] subject sets (also sort of: Agenda for August 6, 2009call)

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

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Thursday, August 06, 2009 4:56 PM

> John Bradley, Nat Sakimura, and myself were present on the call.  So
> perhaps this will be a lesson in what happens when folks don't show up
> on the call :)

I can say the same thing about 'folks who don't show up on the list' :-)
Thursday is becoming my busy day... no idea why but it should clear up soon.
 
> ## Subject Matching Rules ##
> 
> We have at least three potential use cases for matching the value of
> an XRD Subject to something:
> 
> First, in the PKI trust model, a consuming applications trusts the
> signature of an XRD if:
>   - the signature is valid for the document (of course)
>   - the certificate was issued by a trusted certificate authority
>   - the subject of the certificate matches the authority of the XRD
> Subject URI
> 
> Second, when linking from one XRD to another (using the XRD "seeAlso"
> rel value), the XRD/Link/Subject of the first XRD must match the XRD/
> Subject of the second XRD.  Previously we had talked about having an
> implicit value, which was the XRD/Subject of the first XRD (basically,
> the two Subjects had to match), but the current draft of the spec
> requires that the <Link> explicitly define a Subject value, even if it
> is the same as the XRD Subject.

This is wrong. XRD/Link/Subject is optional and if present, simply ads a validation requirements. If it is not there, there is no such validation requirements and it does not default to anything. You simply follow the link regardless of the subject on the other side.

> The third potential use case for Subject matching was a little less
> clear.  This has to do with the first XRD discovered for a given
> resource.  Is the XRD Subject matched against the resource URI which
> was used to discover the XRD document?  I don't believe the language
> is in the spec any more, but there use to be specific mention
> somewhere that it was *not* required to match.  This is because the
> XRD Subject is the canonical URI for the resource, whereas the
> consuming application may have used a non-canonical URI to discover
> the XRD.  This is why we have the Alias element, which lists other non-
> canonical URIs for the resource.  So my question is this:  Is it a
> requirement of XRD Trust that the resource URI used to discover the
> XRD document be present in the document itself, either as the Subject
> or as an Alias?

This is where we venture into the void between LRDD and XRD since XRD begins when you get an XRD document for a resource, but does not tell you how that happened.

But it is somewhat separate from the XRD trust model. The current model is trying to answer:

* Is this XRD authoritative for the resource it claims (via Subject) to describe?

But what you raise is dealing with a different questions:

* Is this XRD authoritative to the resource I performed discovery on?

I think for the trust model to be complete, we need to add some requirement, but do it in a generic way. I am not sure if this belongs in XRD or LRDD. But when put together, it is needed.
 
> A Subject value of "http://example.com/#";
> would satisfy the need for matching the certificate subject, without
> requiring any new schema.

The hash convention is very much in the semantic web world and not something I would like to use or bring into this work.

I think the set construct is much clearer and well defined.

EHL