Re: [xri] XRD trusted discovery workflow

[Brian Eaton <beaton@google.com>]

On Thu, Dec 11, 2008 at 12:05 AM, Dirk Balfanz <balfanz@google.com> wrote:
> I think a URI needs a <Service> context - it seems to me a resource map
> doesn't.
> The current proposal on the wiki says that a resource map is inside a
> service element of type "e-mail to URL translation". We could make that more
> generic, and call it "URI to URI translation", at which point it's saying
> the same thing as URIMap. To me it seems that the following three examples
> all mean the same thing:
> [ my proposal: ]
> <XRD>
>   <URIMap>http://target.com/uri={URI}</URIMap>
> </XRD>

I have two objections to this.

1) What if I want to delegate XRD serving for different services to
different providers?  For example, what if I want PoCo endpoints for
my users served over on poco.example.com, but OpenID endpoints served
over at openid.example.com?  I need a service type field to
distinguish.

2) What if the target on the URIMap is under a different authority,
e.g. http://example.com uses a URIMap to indicate that XRDs will be
served over on http://target.com.  (XRD hosting as a service).  The
target.com server will not be able to sign documents with the
example.com key.  It's really important that we be able to delegate
authority at or before a URIMap.

OK, I guess I have a third objection, counting has never been my
strong suit.  If you accept that we need to be able to delegate
authority at or before a URIMap, and you accept that we might want to
do limited (by service) delegation of authority, it's important that
Delegation be limited to a particular type.