[mdx] GH issue 2: Capability discovery

[Leif Johansson]

On 11/26/2013 05:18 PM, Ian Young wrote:
> 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?
a centralized "discojuice"-like service is one example but anytime you
have a management-interface for adding (say) a new mdx endpoints its
useful to be able to tell the user what that endpoint supports
> * Possibly more interestingly, given a way to discover the capability or lack of it, what would the client in this use case do next?
at the very least help with diagnostics!
>
> 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
We can always profile webfinger for our purpose but this issue is
fundamentally about operations and not about implementation so I don't
think this is an argument
> * It works from well-known URLs at the root of the virtual host, whereas our base URL allows for multiple responders per virtual host
WebFinger uses the resource argument to handle virtual hosts so thats
also not an argument against webfinger.
> * It's really aimed at acquiring information about things *other* than the responder, such as IdP discovery
It can be used for anything related to a URI.
> 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.

I disagree (obviously). I think WF is a pretty good match for what we
want and it is very easily implemented.

As ppl start to deploy OpenIDC in years to come (hopefully OpenIDC will
grow capabilities for multi-party federation in the not too distant
future) our infrastructure will have to do WF anyway.
>
> 	-- Ian
>
>
>
>
>
> _______________________________________________
> mdx mailing list
> mdx at lists.iay.org.uk
> http://lists.iay.org.uk/listinfo.cgi/mdx-iay.org.uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131129/799da2d5/attachment-0002.htm>