RE: [xri] subject matching

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

I don't mean to offend anyone but I want nothing to do with the semantic web. The entire discussion of information resources and using fragment is of no interest to me and not something I am willing to consider for host-meta.

The idea of using https://example.com/.well-known/host-meta for subject came up before and theoretically can be defined by the host-meta protocol to mean the 'host'. But the problem with that is that it prevents describing the document itself. Being able to describe descriptors was a big reason not to use content negotiation for discovery. I am not ready to give that up just because we can't easily find an appropriate string.

If we leave trust out host-meta does not need a subject. But leaving trust out we don't need XRD... that was the only reason why we decided to go that way in the first place.

I hope that the month or so that has passed since we first talked about this will offer a new perspective and maybe some new ideas. I will come back with a few more suggestions and maybe others will do too. I am confident this will not delay our first committee draft.

EHL


> -----Original Message-----
> From: John Bradley [mailto:jbradley@mac.com]
> Sent: Friday, August 21, 2009 5:39 PM
> To: Dirk Balfanz
> Cc: Eran Hammer-Lahav; XRI TC
> Subject: Re: [xri] subject matching
> 
> 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.
> >
> >
> >