<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/19/18 7:16 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5003043C-9135-419E-A046-15BF31104719@osu.edu">
<pre wrap="">On 9/19/18, 7:07 PM, "users on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><users-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">As I just mentioned in my longish reply, the KeyInfo at issue here was the metadata KeyDescriptor/KeyInfo. I don't
*think* Marvin's conclusions here were quite correct, as I believe there would not have been any Credentials extracted
from metadata to filter.
</pre>
</blockquote>
<pre wrap="">
Yes, but my point was that even if the code is outfitted to feed key names into the process to filter out non-matches, that would have to come, ordinarily, from the message's KeyInfo hint. And with a signed redirect, there's no hint, so there's nothing to do but try all the keys in the metadata that match the algorithm type.</pre>
</blockquote>
<br>
Sure. That's what we do. I was just trying to point out that there
was a Keyinfo here (in metadata, not a request hint) and its
"badness" was the root cause here I think, not any kind of filtering
(based on KeyInfo hints or otherwise).<br>
<br>
</body>
</html>