[mdx] GH issue 2: Capability discovery

[Ian Young]

In https://github.com/iay/md-query/issues/4, Leif says:

> Not all MDX-endpoints will be able to serve all metadata formats. Already there is talk in the discojuice project (for instance) about using MDX as a way to query for JSON-based derivatives from SAML metadata.
> 
> It would be useful to be able to ask an MDX server about certain basic capabilities it supports, for instance (not having completely thought any of these through):
> 
> 	• mime types
> 	• well known entity attributes
> 	• trust anchors

First thing to discuss in relation to this is, of course, one or more justifying use cases. So the relevant questions to be asking would be:

* Under what circumstances would one be setting up a client where there was doubt as to whether the responder supported some facility that the client required?

* Possibly more interestingly, given a way to discover the capability or lack of it, what would the client in this use case do next?

Second area of discussion would be around mechanism. At the time we talked about this before, WebFinger was in development and seemed like it might be pointed in the right direction to be useful here. WebFinger is now an RFC so we might base work on top of it if it were appropriate:

	http://tools.ietf.org/html/rfc7033

Having read through the RFC, though, it seems to me that WebFinger is inappropriate for this particular purpose:

* It requires TLS, whereas that is optional for us

* It works from well-known URLs at the root of the virtual host, whereas our base URL allows for multiple responders per virtual host

* It's really aimed at acquiring information about things *other* than the responder, such as IdP discovery

In short, it seems much more in line with the simple REST nature of what we have so far to just serve a capability document of some kind from a well-known path relative to the base URL. That's also pretty trivial for the responder to do, depending on what an empty response would look like (and maybe a 404 would be an acceptable response).

Third area of discussion would be the form of response document. I guess XML, JSON and something like YAML would be the obvious alternatives. I hesitate to suggest the ability to provide capability information in multiple formats, lest we recurse ourselves to death.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131126/12cb5b0e/smime.p7s>