<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 4/25/14 8:24 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF80746D.4D743%25cantor.2@osu.edu" type="cite"><br>
<pre wrap="">
That's true in general, but the common case for that resolver is expected
to be third party oracles providing the metadata, same as now. So you
could configure a static trust engine for InCommon's oracle, etc., not a
dynamically behaving trust engine that is using different credentials for
different entities. Simply because of the obvious problems managing that
as a PKI, it's the reason federations exist. The dynamic resolver changes
distribution but not necessarily trust.</pre>
</blockquote>
<br>
Yeah, that's true, and that's probably the majority case in reality.
<br>
<br>
At the low level of OpenSAML, I wouldn't assume away the other
cases. One assumption there that doesn't strictly hold 100% of the
time is that a metadata oracle (or any publishing endpoint) would be
serving out metadata that is only signed by it. It could simply be
serving as a redistribution point for metadata that is signed by
another party, either the party described by the metadata, or
other. Of course we probably don't want to advocate that model....<br>
<br>
A related case is that of course all of Entities-, Entity-, Role-,
and AffiliationDescriptors can be signed. And potentially by
different parties. That is something that we could see in v2 today
with the non-dynamic metadata providers (e.g. in an
EntitiesDescriptor published by a federation). The filter does walk
the tree and validate them all, but we otherwise handle it
imperfectly, by saying that the static trust engine has to be wired
with all the needed creds. I think this was actually the case I was
thinking of when I put that TODO in the signature filter about
needing to support intelligent logic on how you build the
CriteriaSet that you use to validate those things. But it's
basically the same issue at the code level as the (non majority)
dynamic provider cases - we'd need to support some kind of (probably
pluggable) logic for translating a signed descriptor into any
specific criteria that needs to be fed into the trust engine, like
an EntityIdCriterion or similar.<br>
<br>
But it's true those are all niche cases that we may never even
actually see in the wild.<br>
<br>
<br>
</body>
</html>