RE: [xri] subject matching

["Drummond Reed" <drummond.reed@cordance.net>]

Subject has always been optional (was in XRI Resolution 2.0, when it was
CanonicalID).

=Drummond 

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Friday, August 21, 2009 6:13 PM
> To: John Bradley
> Cc: Dirk Balfanz; XRI TC
> Subject: Re: [xri] subject matching
> 
> Subject is optional.
> 
> On Aug 21, 2009, at 17:38, "John Bradley" <jbradley@mac.com> wrote:
> 
> > If we leave trust out of it for a min.
> >
> > Can't the subject of host meta be anything the host wants to name
> > itself?
> >
> > https://example.com/.well-known/host-meta  as an example.
> >
> > If you want to be pure in the sem web sense then make it:
> > https://example.com/.well-known/host-meta#host-meta
> >
> > That way the subject is a non-information resource.
> >
> > One of the problems is that hot-meta itself is not an information
> > resource.
> >
> > I read the second one to be the XRD found by dereferencing
> https://example.com/.well-known/host-meta
> >  describes the non-information resource https://example.com/.well-
> known/host-meta
> > #host-meta
> >
> > Making subject optional doesn't seem like a appealing idea to me.
> >
> > John B.
> > On 21-Aug-09, at 8:19 PM, Dirk Balfanz wrote:
> >
> >>
> >>
> >> On Fri, Aug 21, 2009 at 3:35 PM, Eran Hammer-Lahav <eran@hueniverse.com
> >>> wrote:
> >> No one is a big fan of this solution.
> >>
> >>
> >> The reasons why 'match' was selected are that it did not require
> >> changing the schema type from URI to string, and it fit the trust
> >> model suggested in which the authority of the subject was compared
> >> to the certificate used to sign. It is very much a hack.
> >>
> >>
> >> I strongly object adding a type to <Subject>. XRD describes web
> >> resources and web resources use the URI namespace.
> >>
> >> It looks like we found a "web resource" (hosts) that can't be named
> >> in this namespace, but that is a legitimate subject of an XRD. I'm
> >> not proposing to re-invent the namespace that is already defined by
> >> URIs. If the subject of the XRD can be described using a URI, we use
> >> type="uri". If it can't, then we use type="somethingelse".
> >>
> >> Your argument sounds to me like you're saying "everything we need
> >> can be described by a URI, so there is no need to come up with a new
> >> namespace". But since the premise seems to be wrong (we can't seem
> >> to figure out how to describe the subject of a host-meta using a
> >> URI), I'm suspecting that the "we don't need a new namespace" may
> >> also be wrong :-).
> >> Inventing another namespace (which is what a type attribute does) is
> >> a really bad idea. At the same time, inventing a new mechanism for
> >> subject sets is out of scope of this work because we don't have any
> >> use cases or requirements beyond host-meta. So the solution has to
> >> be somewhere in between a new subject namespace and a new construct
> >> for subject sets.
> >>
> >>
> >> The concerns raised below regarding the use of match in host-meta
> >> and non-http identifiers is valid, but can be "excused" by saying
> >> that host-meta is really about http resources (something many people
> >> argued for on the IETF list when the topic of email URI came up),
> >> but WebFinger uses it to store its metadata. It is not clean but
> >> allowed. WebFinger is a separate protocol with its own rules and
> >> trust requirements. Does this explanation make me happy? No. But I
> >> can live with it.
> >>
> >>
> >> But since the past few posts make it clear we don't really have
> >> consensus about it, we should attempt to reach a better resolution.
> >> Here are the alternatives I was able to come up with:
> >>
> >>
> >> 1. host-meta will define its own element <Host> and will not use
> >> <Subject>. Since host-meta will not define a trust profile,
> >> WebFinger will need to figure out how to deal with <Host> instead of
> >> <Subject>.
> >>
> >> I could live with that, although it seems a bit of a cop-out.
> >> Clearly, the (upper-case) Host is the (lower-case) subject of this
> >> host-meta, so why not stick it into the (upper-case) Subject element?
> >>
> >> So the idea here would be that as far as XRD (the spec) is
> >> concerned, there would be no Subject in host-metas. And host-meta
> >> (the spec) would say "the subject of a host-meta is in the Host
> >> element". That means we would have to make Subject optional in XRD,
> >> right?
> >>
> >> 2. host-meta will use a DNS URI (something like dns:example.com or
> >> something more complex with SRV record).
> >>
> >> I could live with that, although I predict I won't understand half
> >> of the debate that will undoubtedly break loose when the web purists
> >> get wind of this (because, you know, baby angels die when you
> >> violate dns: URIs like that).
> >>
> >>
> >> 3. host-meta will use a <Link> with extension relation type and the
> >> address of the host-meta file. Clients will need to figure out trust
> >> issues elsewhere.
> >>
> >>
> >> Not sure I understand this proposal.
> >>
> >> I think my vote goes to (1), for now. The more I think about it, the
> >> more I like it - perhaps even more than my own type="host"
> >> proposal :-)
> >>
> >> Dirk.
> >>
> >>
> >>
> >>
> >>
> >> Any more?
> >>
> >>
> >> EHL
> >>
> >>
> >>
> >> From: Dirk Balfanz [mailto:balfanz@google.com]
> >> Sent: Friday, August 21, 2009 2:11 PM
> >> To: XRI TC
> >> Subject: [xri] subject matching
> >>
> >>
> >> Hi guys,
> >>
> >>
> >> I don't like the idea of "subject sets", and in particular the
> >> "beginswith" mechanism to express a certain kind of subject sets.
> >>
> >>
> >> Let me start by explaining how I understand the feature. If I
> >> misunderstood, then much of my rant below will not make sense.
> >>
> >>
> >> An XRD with
> >>
> >>
> >> <Subject>http://www.example.com/foo</Subject>
> >>
> >>
> >> is authoritative for the resource http://www.example.com/foo. If
> >> there is a <Link><Rel>author</Rel><URI>mailto:bob@gmail.com</URI></
> >> Link> in the XRD, it means that the author of
> http://www.example.com/foo
> >> is bob@gmail.com.
> >>
> >>
> >> An XRD with
> >>
> >>
> >> <Subject match="beginswith">http://www.example.com/foo</Subject>
> >>
> >>
> >> is authoritative for all resources that begin with
> http://www.example.com/foo
> >> , which in this case means (1) they're http resources, (2) they're
> >> hosted on www.example.com, and (3) their paths start with /foo. If
> >> there is a <Link><Rel>author</Rel><URI>mailto:bob@gmail.com</URI></
> >> Link> in that XRD, then that means that the author for all the above-
> >> mentioned resources is bob@gmail.com.
> >>
> >>
> >> Am I getting this right so far?
> >>
> >>
> >> As far as I can tell, this design came about as follows:
> >>
> >>
> >> - we decided to make the format of host-meta XRD, which meant we now
> >> have XRDs for hosts (as opposed to just URI-addressable resources).
> >>
> >> - we needed a way to specify the Subject of such a host-meta, which
> >> needs to be a URI.
> >>
> >> - Eran tried to get support for a URI scheme for hosts (or,
> >> alternatively, was asking for better ideas), so we could say
> >> something like <Subject>host:example.com</Subject> to mean that this
> >> XRD is about a _host_, but didn't get much love.
> >>
> >> - As an alternative, this scheme was proposed.
> >>
> >>
> >> My first gripe is that this doesn't seem to solve the original
> >> problem, which was to find a way to say that this XRD is about a
> >> host. Instead, it allows us to say that this XRD is about a set of
> >> (usually http) resources, which is different.
> >>
> >>
> >> My second gripe is that the idea of subject sets doesn't seem to be
> >> compatible with one of the constraints that started us down this
> >> road: that the Subject must be a URI. It is pure coincidence that
> >> the "beginswith" matching rule results in a set-describing pattern
> >> that looks like a URI. If we really believe that being able to
> >> denote a whole set of subjects is an important use case (I haven't
> >> seen evidence of this), then we should put our money where our mouth
> >> is and allow something like this:
> >>
> >>
> >> <Subject match="regex">(http://)|(mailto:)(\s+@)?example.com</
> >> Subject>
> >>
> >>
> >> At this point, Subject is no longer a URI. It's not too surprising
> >> that something that's supposed to describe a set of URIs is not,
> >> itself, a URI. Relying on the fact that the one set-describing
> >> pattern we're currently defining happens to result in patterns that
> >> look like URIs is IMO quite brittle.
> >>
> >>
> >> My third gripe is that it's a hacky solution for things like OpenID
> >> or webfinger. Let's look at webfinger: You start off with an email-
> >> like identifier like joe@example.com, and want to discover meta-data
> >> about it. The steps you need to do are as follows:
> >>
> >>
> >> (1) peel out the host from the identifier (yields "example.com")
> >>
> >> (2) slap the string "http://"; in front of it (yields
> "http://example.com
> >> ")
> >>
> >> (3) Look at the Subject in the host-meta that you believe is
> >> authoritative for this meta-data-resolution. If "http://example.com";
> >> starts with whatever it says in the Subject, then you're looking at
> >> the right host-meta.
> >>
> >> (4) Look for a URITemplate in the XRD, etc., etc....
> >>
> >>
> >> Step (2) is there for no other purpose than to make this hack work.
> >> That's just ugly.
> >>
> >>
> >> My fourth gripe is that I don't understand the trust implications of
> >> subject sets. Trust is something that apps are supposed to develop
> >> their own profiles for, so let's pretend we're trying to do this for
> >> webfinger. With the language we're currently setting up in the spec,
> >> I would think that webfinger would want to say something like this:
> >>
> >>
> >> (1) Extract the host from the identifier (e.g., joe@example.com ->
> >> example.com)
> >>
> >> (2) Find the host-meta for that host (i.e., host-meta for
> >> example.com)
> >>
> >> (3) Make sure that the Subject in the host-meta _matches_
> http://example.com
> >> (we can't say "... _is_ http://example.com";, because such an XRD
> >> would be about the root resource on example.com, which is not what
> >> webfinger is looking for).
> >>
> >> (4) Check that the signature on the XRD is generated by someone
> >> authoritative for the XRD's Subject.
> >>
> >> (5) ....
> >>
> >>
> >> That, however, is not secure. Let's say I somehow ended up with an
> >> XRD that looks like this:
> >>
> >>
> >> <XRD>
> >>
> >>  <Subject match="beginswith">http://example.co</Subject>
> >>
> >>  <Link><Rel>webfinger</Rel><URITemplate>...</URITemplate></Link>
> >>
> >>  <Signature>...</Signature>
> >>
> >> </XRD>
> >>
> >>
> >> (maybe a man-in-the middle injected it as I was fetching
> http://example.com/.well-known/host-meta
> >> , or I got the wrong host-meta from http://hostmetas-r-
> us.com/?domain=example.com
> >> - whatever). The Subject matches http://example.com (according the
> >> current definition in the XRD spec). So now if the XRD is signed by
> >> example.co the signature checks out, and we just got hacked by the
> >> Colombian mafia.
> >>
> >>
> >> I'm not saying that there is no way that webfinger could possibly
> >> define a secure profile, but as you can see, the "obvious" way to
> >> define a trust profile for webfinger resulted in something bad
> >> because the "beginswith" directive interacts strangely with the
> >> trust assumptions.
> >>
> >>
> >> Ok, I think I'm all griped out :-).
> >>
> >>
> >> So, unless some of my assumptions here are wrong, I would like us to
> >> reconsider this beginswith business.
> >>
> >>
> >> Since we don't have URIs that represent hosts, I think our only
> >> option is to relax the requirement that a Subject has to be a URI
> >> (something I believe we're already on the way toward if we want
> >> allow "subject sets").
> >>
> >>
> >> My proposal: have two subject types. One for hosts, one for URIs.
> >>
> >>
> >> <Subject type="uri">acct:joe@example.com</Subject> // describes
> >> Joe's meta data
> >>
> >> <Subject type="uri">http://example.com</Subject> // describes meta
> >> data of root http resource in example.com
> >>
> >> <Subject type="uri">http://example.com/</Subject> // describes meta
> >> data of root http resource in example.com
> >>
> >> <Subject type="host">example.com</Subject> // describes meta-data of
> >> host example.com
> >>
> >>
> >> What do you guys think?
> >>
> >>
> >> Dirk.
> >>
> >>
> >>
> >