But we don't say anything about that anyway. This validation rules is required only in the context of the trust model and is only applied by XRD to following a seeAlso. The spec will define what qualifies as "trusted" link. How applications use it is outside the scope. So I don't think we need to say anything special about it.
EHL
> -----Original Message-----
> From: George Fletcher [mailto:]
> Sent: Friday, August 07, 2009 11:16 AM
> To: Eran Hammer-Lahav
> Cc: Will Norris; XRI TC
> Subject: Re: [xri] subject sets (also sort of: Agenda for August 6,
> 2009 call)
>
>
>
> Eran Hammer-Lahav wrote:
> >> -----Original Message-----
> >> From: Will Norris [mailto:]
> >> 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.
> >
> I would caveat this with ... the link only needs to be followed if the
> processing application is ok with the fact that the trust chain is
> "broken" by the absence of the XRD/Link/Subject. I don't think it
> should
> be mandatory to follow the link. If the use case requires following the
> link to get the required data, then the processing application has to
> make the choice of "broken trust chain" vs "functionality". Something
> we
> do all the time.
>
> Thanks,
> George
> >
> >> 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
>
> --
> Chief Architect AIM: gffletch
> Identity Services Work:
> AOL LLC Home:
> Mobile: +1-703-462-3494
> Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com
