<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/26/2013 05:18 PM, Ian Young
wrote:<br>
</div>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">In <a class="moz-txt-link-freetext" href="https://github.com/iay/md-query/issues/4">https://github.com/iay/md-query/issues/4</a>, Leif says:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
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<br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
* Possibly more interestingly, given a way to discover the capability or lack of it, what would the client in this use case do next?</pre>
</blockquote>
at the very least help with diagnostics!<br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc7033">http://tools.ietf.org/html/rfc7033</a>
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
</pre>
</blockquote>
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 <br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
* It works from well-known URLs at the root of the virtual host, whereas our base URL allows for multiple responders per virtual host
</pre>
</blockquote>
WebFinger uses the resource argument to handle virtual hosts so
thats also not an argument against webfinger.<br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
* It's really aimed at acquiring information about things *other* than the responder, such as IdP discovery
</pre>
</blockquote>
It can be used for anything related to a URI.<br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
I disagree (obviously). I think WF is a pretty good match for what
we want and it is very easily implemented.<br>
<br>
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.<br>
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">
-- Ian
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mdx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mdx@lists.iay.org.uk">mdx@lists.iay.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.iay.org.uk/listinfo.cgi/mdx-iay.org.uk">http://lists.iay.org.uk/listinfo.cgi/mdx-iay.org.uk</a>
</pre>
</blockquote>
<br>
</body>
</html>