Subject and authority

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

I think the reason why we are having such a hard time with dealing with Subject is that we have overloaded this element with too many purposes.

At this point Subject means:

* The context URI of the XRD
* The canonical identifier of the resource the descriptor is associated with
* The source of authority information for establishing trust

Host-meta does not need the first two because they are not defined by the document found at the well-known location but by the protocol. What this means is that if you find a host-meta that does not describe exactly what you expect, the protocol fails. It doesn't allow for other scoped. You also don't stumble upon host-meta files. They must be obtained in a certain way.

What host-meta needs is a trust framework which allows clients to assert that the author and signer of the document intended it to be used as a host-meta file for that specific host, and that it has the authority to do so.

This is not yet a proposal, just something to get a discussion going. This morning I wrote why DeWitt's proposal of expressing Subject and Alias as links is not a good idea. But the only reason not to do so is our dependency on Subject for trust requirements. Expressing Subject as a link makes the document harder to validate because it means having to go dig for an authority.

But what if instead of a Subject and Alias we used links (maybe 'canonical' and 'self'), and we add a new element <Authority> which is a string, and is used by trust profiles. Then each trust profile can make up their own rules about its content, its relation to the canonical URI, and its matching to the certificate used to sign the document.

EHL