Parsing the trust engines

[Cantor, Scott]

On 4/25/14, 12:10 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>In v3, we'll have the capability for the dynamic metadata resolver, where
>that assumption breaks down.  So for that case, you couldn't use a
>Static- credential/PKIX resolver, but rather one which actually honors
>the CriteriaSet passed to the resolver and filters what it returns
>accordingly.

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.

>Just wanted to note this for the record, and also state my current
>understanding that: 1) we don't want to define *new* custom schema
>things, and therefore we would not define any new config schema for
>something like a "CollectionExplicitKeySignature" TrustEngine, and 2)
>that that case would instead be handled by defining such a TrustEngine
>elsewhere via Spring beans and injecting that bean ref to the metadata
>signature filter, i.e. the advanced config cases that we've previously
>mentioned.  Anything wrong with that?

But that is correct, yes. Anywhere we have references to trust engines
now, it should be able to reference something defined with Spring natively.

-- Scott