[mdx] GH issue 2: Capability discovery

[Leif Johansson]

On 11/29/2013 05:35 PM, Ian Young wrote:
>
> On 29 Nov 2013, at 16:15, Leif Johansson <leifj at sunet.se
> <mailto:leifj at sunet.se>> wrote:
>
>>> * 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!
>
> OK, so no proposal for any kind of automated fallback, basically error
> handling if you're using advanced capabilities.
>
>>> * 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
>
> Sorry, I don't understand what you're saying there about "operations".
> Can you rephrase?
I'm saying if you have webfinger then turning on or off tls will be an
operational choice... at some point MDX will have to deal with questions
of the proposed start-tls for http 2.0 (using ephemeral keys) so sooner
or later tls is coming to our show too :-)
>
>>> * 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.
>
> My point is that the place you make WebFinger requests is at a
> location which may be outside the md-query responder's base URL. This
> has implications for implementations: for example, you couldn't
> package the capability responder in the same web application context
> as the rest of the code, and the same webfinger responder would have
> to be able to handle capability discovery for all of the query
> responder contexts on that virtual host.

True but I believe that in practice MDXen (as well as IdPs) will
increasingly be self-contained things and if that doesn't convince you,
you can always do what we always do to manage our URI context: proxy and
rewrite.

>
> Unless I've misunderstood the webfinger spec, that's pretty much a
> deal breaker for me.
>
>>> * 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.
>
> It would be helpful if you could give us an example of the URI you
> think would be used with webfinger to implement capability discovery,
> and the corresponding response you'd like to see.
>
Right, but tomorrow :-)

> -- Ian
>
>
>

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