I don't like the idea of "subject sets", and in
particular the "beginswith" mechanism to express a certain kind of
Let me start by explaining how I understand the feature. If
I misunderstood, then much of my rant below will not make sense.
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:email@example.com</URI></Link> in that
XRD, then that means that the author for all the above-mentioned resources is firstname.lastname@example.org.
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
- 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:
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
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 email@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")
(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:
(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.
That, however, is not secure. Let's say I somehow ended up
with an XRD that looks like this:
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
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
My proposal: have two subject types. One for hosts, one for