<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/29/2013 05:35 PM, Ian Young
wrote:<br>
</div>
<blockquote
cite="mid:1B533521-BB4F-40F4-AB73-B33FB49F67D1@iay.org.uk"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 29 Nov 2013, at 16:15, Leif Johansson <<a
moz-do-not-send="true" href="mailto:leifj@sunet.se">leifj@sunet.se</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">* 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>
</div>
</blockquote>
<div><br>
</div>
<div>OK, so no proposal for any kind of automated fallback,
basically error handling if you're using advanced
capabilities.</div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote
cite="mid:361A81E5-FA50-40DE-BF4A-E54D42AFD47E@iay.org.uk"
type="cite">
<pre wrap="">* 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>
</div>
</blockquote>
<div><br>
</div>
<div>Sorry, I don't understand what you're saying there about
"operations". Can you rephrase?</div>
</div>
</blockquote>
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 :-)<br>
<blockquote
cite="mid:1B533521-BB4F-40F4-AB73-B33FB49F67D1@iay.org.uk"
type="cite">
<div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:1B533521-BB4F-40F4-AB73-B33FB49F67D1@iay.org.uk"
type="cite">
<div>
<div><br>
</div>
<div>Unless I've misunderstood the webfinger spec, that's pretty
much a deal breaker for me.</div>
<div><br>
</div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
Right, but tomorrow :-)<br>
<br>
<blockquote
cite="mid:1B533521-BB4F-40F4-AB73-B33FB49F67D1@iay.org.uk"
type="cite">
<div>
<div><span class="Apple-tab-span" style="font-size: 12px;
orphans: 2; widows: 2; white-space: pre;"> </span><span
style="font-size: 12px; orphans: 2; widows: 2;">-- Ian</span></div>
</div>
<div apple-content-edited="true"><span class="Apple-style-span"
style="border-collapse: separate; border-spacing: 0px;"><span
class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; ">
<div><span class="Apple-style-span" style="font-size:
medium; "><br>
</span></div>
</span></span><br class="Apple-interchange-newline">
</div>
<br>
</blockquote>
<br>
</body>
</html>