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 <
> > 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:]
> 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:</URI></
> Link> in the XRD, it means that the author of http://www.example.com/foo
> is .
>
>
> 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:</URI></
> Link> in that XRD, then that means that the author for all the above-
> mentioned resources is .
>
>
> 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 , 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., ->
> 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:</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.
>
>
>
