Re: [xri] subject matching

[John Bradley <jbradley@mac.com>]

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.
>
>
>