[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] subject matching
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. > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]